Queues

SYSTEM DESIGN SERIES  ·  TOPIC 16 OF 23+  ·  part of the 15 → 16 → 17 chain
1. Whose Problem Is the Waiting?
Same two requests, same slow consumer - watch who's stuck (looping)
No queue: the producer calls the consumer directly and just... waits
No queue: a second request can't even be accepted until the first finishes
No queue: total work done is the same - but the producer is frozen the whole time
With a queue: the producer drops the message and moves on immediately
With a queue: a burst of requests just piles up safely, waiting its turn
With a queue: the consumer still works at its own pace - the waiting just moved
2. What a Queue Actually Buys You
It's not speed - it's decoupling
  • Decoupling - producer and consumer don't need to be up at the same moment
  • Load leveling - a burst gets smoothed into a steady stream (topic 03's limits, protected)
  • Async processing - the caller gets its own latency back (topic 01)
  • Resilience - a crashed consumer (topic 02) can just pick the message back up
📬 A queue is a mailbox, not a phone call. You don't stand there waiting for them to read it.
3. Queue vs Pub/Sub
Queue (Point-to-Point)
  • Each message goes to exactly one consumer
  • Multiple consumers share the work, don't duplicate it
  • Good for: jobs, tasks, work to be done once
VS
Pub/Sub (Broadcast)
  • Every subscriber gets its own copy of each message
  • Adding a subscriber doesn't take work from others
  • Good for: events, notifications, "something happened"
🎟️ Analogy: a queue is a ticket line - one clerk serves each ticket, once. Pub/Sub is a radio broadcast - everyone tuned in hears the exact same thing.
4. Delivery Guarantees - Pick One
This is almost always the actual interview question
At-Most-Once
Fire and forget, no retry. Fast - but a lost message just stays lost.
At-Least-Once
Retries until acknowledged. Nothing is lost - but the same message can arrive twice.
Exactly-Once
The dream. Genuinely hard - usually really at-least-once plus a consumer that can't be fooled twice.
5. Acknowledgment & Poison Messages
How the queue knows a message is really done
  • Ack after processing - safe, but a crash right before the ack means a redo (duplicate)
  • Ack before processing - a crash right after means the message is gone for good
  • A message that fails over and over shouldn't block everything behind it
  • Dead-letter queue: after N failed attempts, set it aside for a human, don't retry forever
6. Real Systems People Actually Use
The same ideas, several implementations
Amazon SQS
RabbitMQ
Kafka
Redis Streams
Different tools same core promise - hand it off, don't hold the line
Kafka keeps a durable, ordered log per partition - closer to pub/sub with history. SQS/RabbitMQ are closer to classic point-to-point queues.
7. When to Reach for a Queue
Use a queue when:
✔ The work can genuinely happen later
✔ Traffic is bursty and needs smoothing
✔ Producer and consumer should scale independently
A Queue Doesn't Make Work Faster - It Makes Waiting Someone Else's Problem
Skip it when:
✔ The caller genuinely needs an answer right now
✔ Volume is low and simple stays simple
✔ The extra hop isn't buying you anything real
💡 At-least-once delivery means your consumer will see duplicates eventually. Handling that safely is Idempotency - topic 17, next.