Delivery guarantees
At-least-once is the industry default — consumers must be idempotent. Exactly-once requires transactional writes or idempotency keys; it's rarely free. Say which one you're picking and why.
Queues — at-least-once, ordering, backpressure.
TL;DR
A queue decouples producers from consumers. Interview points: delivery guarantees (at-least-once vs exactly-once), ordering (FIFO vs partitioned), dead-letter handling, and how backpressure flows when consumers are slow.
Ordering
Global FIFO is expensive and limits throughput. Partitioned FIFO (Kafka-style) orders within a partition key — pick the key that matches your consistency requirement.
Backpressure
Slow consumers fill the queue. Options: drop (lossy), buffer (memory cost), reject producers (load shed), or autoscale consumers. Name the SLO the queue is protecting.
Dead-letter queues
Messages that fail N times go to DLQ. DLQ needs its own alerting and replay path — otherwise it becomes a silent correctness bug.
Frequently asked questions
- At-least-once vs exactly-once delivery?
- At-least-once is simpler and almost always sufficient — consumers must be idempotent. Exactly-once requires transactional writes or idempotency keys and costs throughput.
- How do I handle poison messages?
- Retry with exponential backoff up to N attempts, then route to a dead-letter queue with its own alerting and a manual or scripted replay path.
- Kafka vs SQS vs RabbitMQ?
- Kafka: high-throughput, partitioned FIFO, pull model. SQS: managed, at-least-once, no strong ordering by default. RabbitMQ: AMQP, push model, flexible routing. Pick by throughput target and ordering requirement.
Practice this live.
Book a 45-minute system design mock with a transcript. Included in the $19/mo subscription.