intermediate
RabbitMQ routing keys
Проектируйте routing keys как stable message metadata, а не ad hoc strings, чтобы topic exchange patterns оставались understandable.
Routing key — строка, прикреплённая к сообщению, по которой exchange принимает решение о доставке. Относитесь к ключам как к API-контракту, а не к отладочной строке: используйте иерархию через точку, например `billing.invoice.paid`, чтобы topic-паттерны оставались читаемыми. Producer и consumer должны разделять схему допустимых ключей и правил wildcards.
Topic exchange поддерживает `*` для одного слова и `#` для нуля и более слов. Проектируйте ключи так, чтобы операционные команды могли добавлять подписчиков без переиздания старых сообщений. Не вшивайте волатильные ID в ключи, если паттерны должны оставаться стабильными.
На интервью: предложите соглашение по routing key для жизненного цикла заказа, покажите topic-паттерны и объясните, что ломается при ad hoc ключах.
Типовые ошибки: ключи с префиксами окружения, ломающими production bindings; слишком специфичные ключи без переиспользования; consumer с широким `#`, обрабатывающий чужой трафик.
Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.
Чеклист:
- Определите иерархическое соглашение по ключам.
- Задокументируйте паттерны и wildcards.
- Держите ключи стабильными между деплоями.
- Ревьюйте новые ключи как изменения публичного API.