Queues, Streams, Eventing
RabbitMQ exchanges: build an order-events routing fabric
Reading about exchange types is not the same as wiring a topology that survives a new subscriber, a poison message, and a mistyped binding. Build a small order-events routing fabric, drive real messages through it, and prove each routing decision with evidence — not the producer reporting success.
Turn the unit’s model into a working RabbitMQ topology: pick the right exchange type for selective subscription, add a dead-letter quarantine and an unroutable-message guard, then verify with the management UI and message counts that every event lands exactly where it should.
Design and run a RabbitMQ topology for order events with three consumers (audit, EU-only, fulfilment), prove selective routing works, then make it survive a poison message and a missing binding — demonstrating each behaviour with observed message counts, not assumptions.
- A routing table (queue, binding pattern) plus a per-queue received-count for a known set of published keys, matching what each pattern should catch — measured in the management UI, not predicted.
- The malformed message is shown arriving in the quarantine queue while the work queue is not stuck in a redelivery loop.
- A message with an unmatched routing key is shown captured by the mandatory return (or catch-all binding), proving no silent drop.
- A one-paragraph write-up justifying the exchange type chosen and why direct/fanout/headers would have been a worse fit for selective subscription.
- Add a fanout exchange for a broadcast concern (e.g. cache invalidation) alongside the topic fabric, and explain why broadcast belongs on its own exchange rather than a topic # binding.
- Swap the work queue to a quorum queue and observe the throughput tradeoff under a sustained publish load versus the classic queue.
- Add an alert: instrument the unroutable-message count and the dead-letter queue depth, and trigger a warning when either grows — the on-call signals for a broken binding or a poison-message storm.
- Add a topic-routing test harness that asserts, for a fixed set of routing keys, exactly which queues should receive each — so a future binding change that breaks routing fails the test instead of production.
This is the loop you will run designing any RabbitMQ topology: choose the exchange type from the subscription shape (topic for selective patterns, fanout for true broadcast, direct for fixed point-to-point), bind queues by pattern and verify the copies with real message counts, quarantine poison messages with a dead-letter exchange, and guard against silent drops with the mandatory flag or a catch-all. Doing it once on a toy order-events fabric makes the production version — where a missing binding is invisible until the fraud queue is empty for three days — muscle memory.