RabbitMQ bindings

Binding связывает exchange с очередью по правилам маршрутизации. Direct требует точного совпадения routing key; topic — паттерны вроде `orders.*.created`; fanout игнорирует ключи; headers сопоставляет таблицы заголовков. Несколько bindings позволяют одному сообщению попасть в несколько очередей или маршрутизироваться выборочно.

Bindings должны быть версионируемой инфраструктурой: объявляйте в коде или IaC, ревьюйте в PR и избегайте тихого расхождения между окружениями. При смене маршрутизации сначала добавляйте новые bindings, затем удаляйте старые, чтобы не потерять сообщения.

На интервью: нарисуйте цепочку exchange → binding → queue, объясните доставку в несколько очередей и безопасную миграцию bindings.

Типовые ошибки: осиротевшие bindings после переименования очередей; пересекающиеся topic-паттерны; объявление bindings только при старте consumer; отсутствие владельца каждого binding.

Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.

Чеклист:

• Делайте bindings явными и проверяемыми.
• Документируйте routing key или паттерн для каждого binding.
• Планируйте изменения: сначала добавить, потом убрать.
• Согласуйте владение bindings с границами сервисов.