RabbitMQ bindings

A binding connects an exchange to a queue with optional routing rules. Direct bindings require an exact routing key match; topic bindings use patterns like `orders.*.created`; fanout bindings ignore routing keys; headers bindings match header tables. Multiple bindings let one message fan out to several queues or route selectively.

Bindings should be versioned infrastructure: declare them in code or IaC, review them in PRs, and avoid silent drift between environments. When routing changes, add bindings before removing old ones to prevent message loss during migration.

On interviews: draw exchange → binding → queue flow, explain how one published message can reach multiple queues, and describe a safe binding migration.

Common pitfalls: orphan bindings after queue renames; topic patterns that overlap unexpectedly; declaring bindings only in consumer startup so producers fail first; no documentation of which team owns each binding.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Make bindings explicit and reviewable.
• Document routing key or pattern per binding.
• Plan additive-then-subtractive binding changes.
• Align binding ownership with service boundaries.