RabbitMQ Interview & Revision

RabbitMQ is a general-purpose AMQP message broker built for flexible routing and reliable delivery of discrete messages; Kafka is a distributed commit log built for durable, replayable, high-throughput event streaming. Anchor your answer in the workload: task processing vs. event history.

At-least-once delivery comes from four pieces working together: publisher confirms (producer knows the broker accepted the message), an appropriately durable/replicated queue plus persistent messages (survives broker crash), manual consumer ACK (survives consumer crash), and idempotent handling of duplicates (because redelivery after a crash-before-ACK can still cause double-processing). Explain what breaks if any piece is missing.

Direct (exact routing-key match), fanout (broadcast, ignores routing key), topic (wildcard pattern match with * and #), headers (match on message metadata, not routing key). Give a one-line use case for each.

RabbitMQ detects the dropped connection/channel and requeues any unacknowledged messages held by that consumer, making them available for redelivery — typically to a different, healthy consumer.

Configure a Dead Letter Exchange (DLX) on the queue, bind a Dead Letter Queue to it, and cap retry attempts — typically via a custom header, checked against the broker-maintained x-death array that records how many times a message has been dead-lettered. After N failures, route to the terminal DLQ instead of retrying again.

Prefetch (QoS) limits how many unacknowledged messages the broker will push to a consumer at once. Lower prefetch means fairer dispatch across consumers; higher prefetch means more buffering and throughput potential but a bigger redelivery blast radius on crash. The right value depends on message processing time and consumer uniformity, not a fixed default.

Distinguish processing scale from availability: adding consumers to a queue is the first lever for parallel processing, but the queue/broker and downstream capacity eventually become the bottleneck, so queue/workload distribution across nodes can matter too. Quorum queues address replicated availability and data safety on node failure — a separate concern from throughput scaling, not simply a capacity mechanism.

A producer publishes with routing key "orders.created" to a topic exchange with a binding pattern "orders.*" — does it match? What about "orders.#"? (Answer: both match — * matches the single word 'created'; # matches zero-or-more words including exactly one.)

You set prefetch=0 on a consumer. What happens under a burst of 10,000 messages with only one consumer online? (Answer: prefetch=0 removes the QoS limit, so the consumer can accumulate a very large unacknowledged backlog — actual delivery is still constrained by transport/client/broker flow, but there's no broker-enforced cap, which risks consumer memory pressure and a large redelivery blast radius if it crashes.)

A queue has no DLX configured and a consumer keeps rejecting the same malformed message with requeue=true. What happens? (Answer: infinite requeue loop — the message keeps being redelivered forever, consuming consumer capacity with no resolution. If it were rejected with requeue=false instead, dead-lettering or discard would apply per the queue's configuration.)

Why can't a standard RabbitMQ queue replay a message to a second consumer group the way Kafka can? (Answer: RabbitMQ deletes a message once ACKed by its consumer — there's no retained log to replay from under normal queue semantics; a second queue would need to exist via a binding before the message was published. RabbitMQ Streams provide a different retained/replayable model if that capability is genuinely needed.)