Messaging interviews come in two shapes. Knowledge questions ("what does acks=all do?") check that you know the mechanism. Design questions ("design a notification service") check that you can turn requirements into broker choices, keys, failure handling and monitoring. The first half of this page drills the first shape in six themes; the second half gives you a repeatable method and six worked design prompts.

• Lead with the one-sentence answer, then the mechanism, then the trade-off. "Kafka keeps order only inside a partition, so messages that must stay in order share a key. The cost is that one hot key limits parallelism."
• Name the failure. Strong candidates talk about what goes wrong: duplicates, poison messages, rebalances, full disks. Weak ones describe only the happy path.
• Say "it depends" and then say on what. "Kafka or SQS?" depends on replay, fan-out, volume, ordering needs and who runs it. Name those axes.
• Never claim exactly-once end to end. The accurate sentence is "at-least-once delivery plus idempotent processing gives an exactly-once effect" (page 01).
• Tie every answer to a number you would watch. That signals operational experience (page 08).

Concept questions that apply to every broker. Background: 01 Messaging Fundamentals.

• Q: Why use a message broker instead of calling a service directly?
  To decouple the sender and receiver in time and availability. The producer does not wait for the consumer, a slow or down consumer does not fail the producer, bursts are absorbed by the buffer, and one message can reach many consumers. The costs are eventual consistency, more moving parts, and the need to handle duplicates and failures explicitly.
• Q: Explain at-most-once, at-least-once and exactly-once delivery.
  At-most-once acknowledges before processing: a message can be lost, never duplicated. At-least-once acknowledges after processing and retries until acknowledged: never lost, possibly duplicated, and the default for almost everything. Exactly-once over an unreliable network is not achievable end to end; it is at-least-once delivery combined with idempotent processing, so the effect happens once.
• Q: How do you make a consumer idempotent?
  Prefer natural idempotency (set absolute state, upsert by business key, version checks). Otherwise record processed message ids in a table with a unique constraint, inserted in the same transaction as the business change, and skip on a conflict. Keep dedup rows at least as long as a message can be redelivered.
• Q: A command, an event and a document: what is the difference?
  A command asks one receiver to do something and can be refused ("charge this card"). An event states a fact that already happened and has any number of listeners ("order placed"). A document carries data for a receiver to use. Events and commands need different contracts, naming and ownership.
• Q: How is ordering preserved, and what does it cost?
  Ordering is only guaranteed within a single ordered lane (a Kafka partition, an SQS FIFO message group, one RabbitMQ queue with one consumer). Messages that must stay in order share a key that routes them to the same lane. The cost is parallelism: one lane is processed by one consumer at a time.
• Q: What is backpressure?
  The mechanism by which a slow consumer limits the rate of its producer so the system does not overflow. In practice you choose in advance between buffering (let the queue grow and scale out), slowing the producer (bounded buffers, rate limits) and shedding load (drop stale or low-value work).
• Q: What is a poison message and a dead-letter queue?
  A poison message is one that always fails, so retrying forever blocks the lane or burns resources. After a bounded number of retries it is moved to a dead-letter queue with failure metadata so the lane keeps flowing, and a person or a job inspects it. A DLQ without an alert and an owner is a silent data-loss mechanism.
• Q: Why do duplicates happen even in a reliable system?
  Because "reliable" means "never lost", and the only way to guarantee that over a network is to resend when unsure. A consumer that crashes after processing but before acking, a producer that retries after a lost acknowledgment, or a timeout that hands the message to a second consumer all create duplicates.

Background: 02 Kafka Architecture, 03 Kafka Producers & Consumers, 04 Kafka with Spring. Facts below match Apache Kafka 4.0.

• Q: How is Kafka different from a traditional message queue?
  Kafka is a partitioned, replicated, append-only log. Messages are retained for a configured time or size regardless of whether they were read, each consumer group tracks its own offset, and any group can replay. A queue deletes a message once acknowledged and tracks delivery per message.
• Q: What is a partition and what does it determine?
  One ordered log of a topic. It is the unit of ordering (order holds only within it), of parallelism (one consumer per partition within a group), of replication and of deletion (retention removes whole segments). A record is addressed by topic, partition and offset.
• Q: Explain leader, follower, ISR and high watermark.
  Each partition has one leader that handles all reads and writes; followers copy from it. The in-sync replicas are the leader plus followers that are caught up within replica.lag.time.max.ms (30 s by default). The high watermark is the highest offset replicated to all ISR members, and consumers read only below it.
• Q: How do you configure Kafka so acknowledged data is never lost?
  Replication factor 3, min.insync.replicas=2, producer acks=all with idempotence on, unclean.leader.election.enable=false, and replicas spread across racks or zones. That survives one broker failure without loss and refuses writes instead of risking loss when two are down.
• Q: What does the idempotent producer fix, and what does it not?
  It stops retries by the same producer session from creating duplicates in a partition, using a producer id and per-partition sequence numbers. It is on by default in Kafka 3.0 and later (with acks=all, retries above 0 and at most 5 in-flight requests). It does not stop your application from sending the same business event twice, and it does not span restarts of the process.
• Q: What are Kafka transactions and what do they guarantee?
  A producer with a transactional.id can write to several partitions and commit the consumer offsets atomically (sendOffsetsToTransaction), so a read-process-write cycle inside Kafka either all happens or none of it. Consumers see only committed data when isolation.level=read_committed (the default is read_uncommitted). This is exactly-once within Kafka; effects in a database or an HTTP call are outside it.
• Q: How do consumer groups and rebalancing work?
  The partitions of a subscribed topic are divided among the members of a group, one owner per partition. When members join, leave or are considered dead (no poll within max.poll.interval.ms, default 5 minutes, or no heartbeat within session.timeout.ms, default 45 s) the group rebalances. With the classic protocol that pauses affected consumers, which is why cooperative assignment, static membership and the KIP-848 protocol in 4.0 matter.
• Q: When do you commit offsets, and what goes wrong at each choice?
  Committing after processing gives at-least-once: a crash between processing and commit repeats messages. Committing before processing gives at-most-once: a crash loses them. Auto-commit (enable.auto.commit defaults to true) commits on a timer, which can commit messages you have polled but not finished. Prefer manual commits after the work is done.
• Q: What happens if you add partitions to a keyed topic?
  The mapping from key to partition depends on the partition count, so existing keys can start landing on different partitions, breaking per-key order and any state keyed by partition. Partitions can be added but never removed, so choose the count with headroom up front.
• Q: Delete versus compact cleanup policy?
  delete removes old segments by age or size (7 days by default). compact keeps at least the latest record per key and removes older ones in the background; a null value is a tombstone that deletes the key after delete.retention.ms. Compaction suits "latest state per key" topics, not event history.
• Q: What changed with KRaft?
  Cluster metadata moved from ZooKeeper into an internal Raft-replicated log (__cluster_metadata) managed by controller nodes. ZooKeeper support was removed in Kafka 4.0, so KRaft is the only mode, and one fewer system has to be operated.

Background: 05 RabbitMQ. Facts match RabbitMQ 4.x.

• Q: Describe RabbitMQ's routing model.
  Producers publish to an exchange, never directly to a queue. The exchange routes each message to bound queues by rules: direct (exact routing key), topic (pattern with * and #), fanout (every bound queue) and headers (header matching). Consumers read from queues. The default exchange routes by queue name.
• Q: How do acknowledgments work, and what are publisher confirms?
  A consumer acknowledges a delivery after processing; an unacknowledged message is redelivered if the channel closes. In the other direction, publisher confirms let the broker tell the producer that it has taken responsibility for a message. Without confirms a publish can be lost silently; with consumer acks and publisher confirms you get at-least-once end to end.
• Q: What is prefetch and why does it matter?
  It limits how many unacknowledged messages the broker sends a consumer. Too high and one consumer hoards messages while others idle, and a crash redelivers a large batch; too low and the consumer waits on the network. The count of unacknowledged messages is a key metric.
• Q: What are quorum queues and how do they differ from classic queues?
  Quorum queues are replicated, durable queues based on the Raft consensus protocol: a message is confirmed once a majority of replicas have it, and a queue stays available while a majority is online. They are the recommended type for data safety. Classic mirrored queues were removed in RabbitMQ 4.0.
• Q: How does RabbitMQ handle poison messages?
  Failed messages can be rejected without requeue and routed by a dead-letter exchange. Quorum queues also count failed deliveries (x-delivery-count) and, from RabbitMQ 4.0, dead-letter or drop after a delivery limit that defaults to 20, configurable with the delivery-limit policy.
• Q: What happens when RabbitMQ runs out of memory or disk?
  A resource alarm blocks connections that publish (the node stops reading from them) while consumers keep working, so a backlog can turn into a publisher outage. The memory alarm triggers at the vm_memory_high_watermark (default 0.6 of RAM) and the disk alarm at disk_free_limit.
• Q: When would you choose RabbitMQ over Kafka?
  When you need flexible routing, per-message acknowledgment, priorities or TTLs, request-reply, and task-queue semantics at moderate volume, and you do not need long retention or replay. Choose Kafka when the event stream and replay are the product, volumes are high, or many independent consumers read the same data.

Background: 06 AWS Messaging. Numbers below were checked against the Amazon SQS developer guide.

• Q: Standard versus FIFO SQS queues?
  Standard queues have nearly unlimited throughput, at-least-once delivery and best-effort ordering, so duplicates and reordering happen. FIFO queues keep order within a MessageGroupId and deduplicate sends (deduplication id) within a 5-minute window, at lower throughput limits (see the quotas page). Use FIFO only when order or send-side dedup is required.
• Q: What is the visibility timeout?
  When a consumer receives a message it becomes invisible to others for the visibility timeout (default 30 seconds, maximum 12 hours). If the consumer deletes it in time, done; if not, the message becomes visible again and is redelivered. Set it above your worst-case processing time, or extend it with ChangeMessageVisibility.
• Q: How does the SQS dead-letter queue work?
  A redrive policy on the source queue names a DLQ and a maxReceiveCount: after that many receives without a delete, SQS moves the message to the DLQ. The DLQ must be in the same account and Region and must be the same queue type. Give the DLQ a longer retention period than the source queue, because for standard queues expiry is based on the original enqueue time.
• Q: How do you redrive a DLQ?
  Fix the cause first, then use the message move task (console "Start DLQ redrive", or StartMessageMoveTask) to move messages back to the source queue or another queue of the same type, with a maximum rate (up to 500 per second) that you ramp gradually. You cannot filter or modify messages during the move (page 08).
• Q: How do SNS and SQS work together?
  SNS is publish/subscribe: a topic fans a message out to subscribers. Subscribing an SQS queue per consumer gives each consumer its own durable buffer, retries and DLQ, so a slow consumer does not affect the others. The queue policy must allow the topic to send. SNS also supports cross-Region delivery to SQS queues.
• Q: Kafka (or MSK) versus SQS versus Kinesis?
  SQS: simple, fully managed task queue, no ordering unless FIFO, no replay. Kafka or MSK: log with long retention, replay, many consumer groups and high throughput, more to design and operate. Kinesis: AWS-native streaming with shards, similar in spirit to Kafka. Pick by replay need, fan-out, ordering, volume and operational appetite.
• Q: What is the maximum SQS message size, and what do you do with larger payloads?
  The maximum is 1 MiB (1,048,576 bytes). For larger data store the payload in S3 and send a reference, or use the SQS Extended Client Library.
• Q: What is long polling and why use it?
  A ReceiveMessage call that waits for up to 20 seconds for a message to arrive instead of returning immediately. It reduces empty responses, API cost and latency. Short polling is the default if you do not set a wait time.

Background: 07 Event-Driven Patterns.

• Q: What is the dual-write problem and how does the outbox solve it?
  Saving to a database and sending to a broker are two systems with no shared transaction, so a crash between them leaves an order without an event or an event without an order. The transactional outbox writes the business row and an event row to an outbox table in one local transaction, and a separate relay publishes the outbox rows, retrying until they are sent. It turns a lost event into a possible duplicate.
• Q: Polling relay versus change data capture for the outbox?
  A polling publisher queries the outbox table periodically: simple, but adds database load and latency and needs care with ordering. Log-based CDC (for example Debezium) reads the database transaction log and streams outbox rows with low latency and no polling load, at the price of running another component.
• Q: What is the inbox pattern?
  The receiving side of the same idea: record each processed message id in a table inside the same transaction as the business change, so a redelivered message is detected by the unique constraint and ignored. It makes at-least-once delivery harmless.
• Q: Choreography or orchestration for a saga?
  In choreography each service reacts to events and emits its own, with no central coordinator: loosely coupled but the overall flow is hard to see. In orchestration a coordinator tells each participant what to do next and handles compensation: easier to follow and monitor, but it is a central component. Prefer orchestration as flows grow beyond a few steps.
• Q: What is a compensating action?
  A saga cannot roll back across services, so each step that has an effect has a second step that semantically undoes it (refund a payment, release stock). Compensations must themselves be idempotent and retryable, and some effects (an email sent) cannot be undone and need a different treatment.
• Q: What is CQRS and when is it worth it?
  Command Query Responsibility Segregation separates the write model from one or more read models, usually fed by events. It pays off when reads and writes have very different shapes or scale. It costs eventual consistency between the two sides and more infrastructure, so it is not a default.
• Q: What does event sourcing cost?
  You store the sequence of events as the source of truth and derive state by replaying them, which gives a full audit trail and time travel. The costs are schema evolution of old events forever, rebuilding projections, snapshots for long streams, and a steep learning curve for the team.

Background: 08 Reliability & Operations.

• Q: Consumer lag is growing. What do you do?
  Work through three checks in order. Is the consumer running and polling (crashed, stuck, or being rebalanced)? Is it slow (processing time, a dependency, a recent deploy; produce rate versus consume rate)? Is the lag skewed to one partition (hot key or poison message)? Fix the cause; add consumers only up to the partition count and only if the dependency can take the load.
• Q: What do you alert on for a queue, and why?
  The age of the oldest message (on SQS ApproximateAgeOfOldestMessage, on Kafka lag in time), because it is the delay users feel and is independent of volume. Queue depth alone fires on harmless bursts. Add DLQ depth above zero, under-min-ISR and offline partitions for Kafka, and resource alarms for RabbitMQ.
• Q: How do you restart a Kafka cluster with no downtime?
  One broker at a time with controlled shutdown so leaders move first, then wait until under-replicated partitions return to 0 before touching the next. Replication factor 3 and min.insync.replicas=2 are what make a single broker outage safe.
• Q: How do you redrive a DLQ safely?
  Inspect to find the cause, fix and deploy, test with a few messages, redrive at a limited rate while watching the consumer error rate and queue age, and make sure consumers are idempotent because some of these messages may have had partial effects.
• Q: Producers report NotEnoughReplicas. What is wrong?
  The in-sync replica set of some partitions is below min.insync.replicas, so acks=all writes are rejected. Check kafka-topics.sh --describe --under-min-isr-partitions, find which broker is down or out of sync (disk, network, overload) and restore it. Do not lower min.insync.replicas to silence the error.
• Q: What is a rebalance storm?
  Consumers that exceed max.poll.interval.ms or miss heartbeats are evicted, which triggers a rebalance that pauses everyone, grows the backlog and makes the next batch slower, so more consumers are evicted. Reduce batch size, fix pauses, use static membership and cooperative assignment, and avoid a flapping autoscaler.

Design prompts are open on purpose. The interviewer wants to see your process, so give them one. Use the same six steps every time; it keeps you from jumping to "use Kafka" before knowing what the problem is.

Each prompt below shows the outline of an answer an interviewer would be happy with, in the order of the method from chapter 8. Treat the numbers as examples of the kind of reasoning, not as facts about any real system.