RabbitMQ routing keys

Routing keys are strings attached to published messages that exchanges use for delivery decisions. Treat them as API contracts, not debug strings: use hierarchical dot-separated names like `billing.invoice.paid` so topic patterns remain readable. Producers and consumers should share a schema for allowed keys and wildcard rules.

Topic exchanges support `*` for one word and `#` for zero or more words. Design keys so operational teams can add subscribers without republishing old messages. Avoid embedding volatile IDs in keys when patterns must stay stable.

On interviews: propose a routing key convention for an order lifecycle, show matching topic patterns, and explain what breaks if keys are ad hoc.

Common pitfalls: routing keys with environment-specific prefixes that break production bindings; over-specific keys that prevent reuse; consumers binding to overly broad `#` patterns and processing unrelated traffic.

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

Checklist:

• Define a hierarchical key convention.
• Document allowed patterns and wildcards.
• Keep keys stable across deployments.
• Review new keys like public API changes.