RabbitMQ, JMS & Messaging Models — Interview Questions

How to use this lesson

Know when a message broker (RabbitMQ, ActiveMQ, SQS: smart routing, per-message acknowledgement, work queues) fits better than a log (Kafka: replayable streams, high throughput, ordering per partition). Senior answers compare their delivery guarantees, and their operational models.

Q1. What's the difference between a queue and a topic in JMS? Point-to-point vs publish-subscribe?

Short answer:

• Point-to-point (a JMS queue): each message is consumed by exactly one consumer, among possibly many competing ones. That gives load-balanced work distribution (order processing jobs). Messages wait in the queue until they're consumed and acknowledged.
• Publish-subscribe (a JMS topic): each message is delivered to every subscriber, for broadcast or fan-out (price updates, notifications). Non-durable subscribers only receive messages while connected. Durable subscriptions (and JMS 2.0 shared subscriptions, for load-balancing within a subscription) retain the messages for offline subscribers.
• In RabbitMQ, these map to exchanges plus bindings: a queue bound to a direct exchange gives point-to-point, and a fanout or topic exchange bound to several queues gives pub/sub, where each queue gets a copy, and consumers on each queue compete. In Kafka, it's a topic plus consumer groups: within a group it's point-to-point, and across groups it's pub/sub.

Q2. What's the difference between RabbitMQ and Kafka?

Short answer:

They're often used together: Kafka for the event backbone, and RabbitMQ or SQS for work queues. RabbitMQ Streams and quorum queues narrow the gap somewhat.

Learn it in depth → Messaging Technology Choices

Q3. How does message acknowledgement work in RabbitMQ?

Short answer:

• Consumer acknowledgements:
  • with manual ack mode, the broker delivers messages, and keeps them unacknowledged until the consumer sends basic.ack (remove it), basic.nack/basic.reject with requeue=true (redeliver) or requeue=false (drop, or dead-letter it if a DLX is configured);
  • if the consumer's channel or connection closes with unacked messages, they're redelivered (the redelivered flag is set);
  • auto-ack mode ("fire-and-forget") acknowledges on delivery, so a crash loses the message.
• Spring AMQP: AcknowledgeMode.AUTO (the container acks after the listener returns successfully, and nacks or rejects on an exception, with configurable requeue behaviour), MANUAL (channel.basicAck(tag, false)), or NONE.
• Beware of poison messages with requeue=true: they loop forever. Set the delivery limits (quorum queues' x-delivery-limit), and dead-letter them.

Q4. What are prefetch limits, and why do they matter in RabbitMQ?

Short answer: Prefetch (basic.qos) caps how many unacknowledged messages the broker pushes to a consumer or channel at once. Spring's prefetchCount defaults to 250. Why it matters:

• too high: one consumer hoards messages, while the others sit idle (poor load balancing); memory bloats on the consumer; and many messages are redelivered at once on a crash;
• too low (for example 1): lower throughput, because of a round trip per message, though it gives the fairest distribution for slow, uneven tasks;
• tuning: fast, uniform messages → a higher prefetch (50–300); slow or expensive jobs → a low prefetch (1–10). Combine it with the consumer concurrency.

It's RabbitMQ's back-pressure mechanism for consumers.

Q5. How do you ensure reliable delivery in RabbitMQ?

Short answer: Cover publisher → broker → consumer:

• Publisher side:
  • publisher confirms (the broker acknowledges once the message is persisted or enqueued; Spring publisher-confirm-type: correlated, with a callback);
  • mandatory flag / returns for unroutable messages (publisher-returns, a ReturnsCallback);
  • retries on nack or timeout;
  • an outbox for atomicity with the database.
• Broker side:
  • durable exchanges and queues;
  • persistent messages (deliveryMode=2);
  • quorum queues (Raft-replicated across nodes, the recommended HA queue type; classic mirrored queues were removed in 4.0);
  • disk and memory alarms monitored.
• Consumer side:
  • manual or auto ack after successful processing;
  • idempotent handling (redeliveries happen);
  • a DLX for failures;
  • bounded retries (Spring Retry interceptor, or delayed requeue).
• Clustering and operations: a 3+ node cluster, quorum queues, monitoring (queue depth, unacked counts, consumer utilisation), and alerts.

Q6. What's a dead-letter exchange in RabbitMQ for?

Short answer: A dead-letter exchange (DLX) receives messages that a queue can't deliver or process:

• messages rejected or nacked with requeue=false;
• TTL-expired messages (per-message or per-queue x-message-ttl);
• messages dropped because the queue length limit was reached (x-max-length with the drop-head overflow policy);
• quorum-queue messages exceeding their delivery limit.

Configure it on the queue with the x-dead-letter-exchange (and optional x-dead-letter-routing-key) arguments. The DLX routes to a dead-letter queue, for inspection, alerting and replay. The x-death header records why, how many times, and where from. It's used for poison-message isolation, and (with TTL) for delayed retries.

Q7. How do you implement delayed or scheduled messages in RabbitMQ?

Short answer:

• The TTL + DLX pattern: publish to a "wait" queue with no consumers, and a message TTL (for example 30 seconds) plus a DLX pointing back to the work exchange. When the TTL expires, the message is dead-lettered into the work queue. Use one wait queue per delay tier (a queue only expires messages from its head, so mixed per-message TTLs block each other).
• The delayed message exchange plugin (rabbitmq_delayed_message_exchange): the x-delayed-message exchange type, with an x-delay header per message. It's simpler, but the delayed messages are stored on a single node (with limited HA and scale).
• Spring AMQP: set the x-delay header (MessageProperties.setDelay) with a delayed exchange, or declare the TTL/DLX queues as beans.
• For long, precise or large-scale scheduling, use a scheduler (Quartz, a database-backed job table, or a cloud scheduler such as EventBridge Scheduler) that publishes when it's due, rather than parking millions of messages in the broker.

Q8. What's the role of message converters in Spring AMQP?

Short answer: A MessageConverter turns Java objects into AMQP Message bodies plus properties, and back:

• the default SimpleMessageConverter handles String, byte[] and Java-serialised objects. Avoid Java serialisation: it's insecure, and coupled to the classes;
• Jackson2JsonMessageConverter (the common choice) writes JSON, and sets content_type and type-id headers (__TypeId__). Configure a trusted packages or type mapper (DefaultJackson2JavaTypeMapper, with an allowed class list, or TypePrecedence.INFERRED from the listener's parameter type) to avoid deserialisation attacks and coupling to producer class names;
• others: XML (Jaxb2), Avro or Protobuf (custom), and ContentTypeDelegatingMessageConverter (chosen by content type).

Register the converter on the RabbitTemplate and the listener container factory. @RabbitListener methods can then take typed payloads (void on(OrderPlaced event)) with @Payload/@Header arguments.

Q9. How do you enable transactional messaging in JMS?

Short answer:

• Local JMS transactions: create a transacted session (connection.createSession(true, …), or JmsTemplate.setSessionTransacted(true), or listener containers with sessionTransacted=true). Sends and receives within the session are committed or rolled back together (session.commit()/rollback()). On rollback, the received messages are redelivered.
• Spring: a JmsTransactionManager, with @Transactional, for JMS-only transactions. DefaultMessageListenerContainer with sessionTransacted=true rolls back and redelivers on a listener exception.
• JMS plus database atomically:
  • XA/JTA (JtaTransactionManager, with Atomikos or Narayana), with XA-capable brokers and datasources. It's heavy, slower, and has operational pitfalls;
  • or, preferably, "best-effort 1PC" (commit the database first, then the JMS session, synchronised by Spring) plus idempotent consumers;
  • or the outbox pattern.
• The caveat: broker redelivery policies (max redeliveries, then the DLQ, as in ActiveMQ's DLQ) should be configured to avoid infinite rollback loops.

Q10. RabbitMQ vs Kafka: how do you choose for a new system? (The decision summary)

Short answer: Choose Kafka when you need durable event streams consumed by many independent services, replay and reprocessing, high throughput, stream processing (Kafka Streams or Flink), or CDC pipelines. Choose RabbitMQ (or SQS) when you need work queues with per-message acknowledgement, retries, priorities or delays, complex routing, RPC-style request-reply, or lower operational weight for moderate volumes. Many platforms use both.

Follow-up questions this topic invites — and their answers

Q: What are quorum queues? A: RabbitMQ's replicated, durable queue type, based on Raft. They give data safety across node failures, poison-message handling (delivery limits), and predictable failover. They're the recommended default for durable workloads, replacing classic mirrored queues.

Q: How do competing consumers affect ordering in RabbitMQ? A: With several consumers on one queue, messages are processed concurrently, so global ordering isn't preserved. For per-entity ordering, use consistent-hash exchanges or single active consumer (x-single-active-consumer), or partition across several queues by key.

Q: What is JMS 2.0's simplified API? A: JMSContext (combining the connection and session), JMSProducer/JMSConsumer, method chaining, shared subscriptions, and asynchronous send. Jakarta Messaging continues it (jakarta.jms). Spring's JmsTemplate/JmsClient wrap it.

Q: How does Amazon SQS compare? A: It's a fully managed queue: at-least-once standard queues, or FIFO queues (ordering plus deduplication, with throughput limits), visibility timeouts instead of acks, DLQ redrive policies, and long polling. There are no brokers to run, but routing is limited (combine it with SNS for fan-out).