RabbitMQ Engineering Insights

You need complex routing (direct/topic/headers), priority queues, RPC-style request/reply, or acknowledgement/redelivery-oriented processing for discrete units of work — background jobs, task queues, transactional side-effects.

You need to replay history, support many independent consumer groups reading the same stream at different speeds, or sustain very high throughput with strict ordering per partition key — event sourcing, analytics pipelines, CDC.

RabbitMQ pushes to consumers and removes a message from the queue once acknowledged. Kafka is pull-based and retains messages in the log for a configured retention period regardless of whether any consumer has read them — a deliberate capability RabbitMQ Streams also provides within RabbitMQ, narrowing this distinction for that specific feature.

RabbitMQ preserves order within a single queue with a single active consumer — add consumers, or allow redelivery after a NACK, and strict cross-message ordering is no longer guaranteed. Kafka preserves order strictly within a partition, for the configured retention period, across any number of consumer groups.

Queue holds M1, M2, M3 in order. With one consumer, they are processed M1 → M2 → M3. Add a second consumer: the broker delivers M1 to consumer A and M2 to consumer B at nearly the same time. If A is slow, B finishes and ACKs M2 first, so the effects of M2 land before M1's. If A then NACKs M1 with requeue, it returns to the queue and may be delivered again after M3 has already been handled. Delivery order is preserved; processing order across consumers is not. If order matters per entity, use a single active consumer, or route by key so each entity maps to one queue and one consumer.

One topic exchange per bounded context (e.g. orders-events), with routing keys like orders.created, orders.cancelled. New consumers bind new queues with new patterns without touching the producer.

A dedicated fanout exchange for events every service might care about (config changes, cache invalidation) — decouples the publisher completely from who's currently listening.

A dedicated DLX + DLQ pair per meaningful queue keeps failure triage scoped to the right team, at the cost of more topology to manage than a shared DLQ. For low-traffic or closely-related queues, a shared DLQ with queue-name metadata on the dead-lettered message can be a reasonable trade-off instead.

<domain>.<entity>.<action> (e.g. orders.order.created) lets topic bindings scope broadly (orders.#) or narrowly (orders.order.created) without redesigning exchanges.

Encoding schema version in the routing key (orders.created.v2) fragments bindings, since every consumer binding has to be updated to match a new version. Versioning the message payload/schema while keeping routing keys stable is usually simpler to operate — though a routing-key version can be the right call when different versions genuinely need independent routing (e.g. a gradual migration where old and new consumers must not see each other's messages).

Trades a small latency win for a real chance of silent message loss on consumer crash. See Fundamentals' Delivery Guarantees for the ACK mechanics.

Poison messages loop forever or vanish silently. See Production Engineering's Dead Letter Queues chapter for the operational recommendation.

An unexamined prefetch value can starve some consumers while overloading others. See Production Engineering's Prefetch Count Tuning chapter.

Forgetting durable=true (or persistent messages, or a replicated queue type) means a broker restart or node failure can silently lose data that mattered. See Fundamentals' Delivery Guarantees.

Opening a new AMQP connection per request instead of reusing a connection pool (with many lightweight channels) exhausts broker file descriptors under load.

Yes — if multiple bindings match (e.g. a fanout exchange, or a topic exchange with overlapping patterns), the exchange delivers a full independent copy to each matching queue.

Yes, via basic.get, but it's discouraged for regular consumption — it's far less efficient than the push-based basic.consume model and is really meant for one-off polling/debugging.

Web app publishes a job (send email, generate report, resize image) to a durable queue; a horizontally-scaled worker pool consumes with manual ACK and tuned prefetch, with a dead-letter strategy for permanently failing jobs.

Each service publishes domain events to its own topic exchange; other services bind their own queues with the routing key patterns they care about — new consumers can be added with zero changes to the publisher.