Distributed Systems · core
Message Queues
Kafka, SQS, exactly-once vs at-least-once.
Mental model
A queue decouples producer speed from consumer speed and turns a sync call into a durable, retryable message. 'Exactly once' is mostly a myth — design for at-least-once delivery plus idempotent consumers.
How to study Message Queues
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use Message queue (Wikipedia), Apache Kafka documentation to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare Message Queues with Retries & DLQ, Background Jobs. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Queue backpressure and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
Kafka, SQS, RabbitMQ; ingestion and event pipelines.
Common mistakes
- Assuming exactly-once delivery
- Non-idempotent consumers on an at-least-once queue
- Ignoring ordering guarantees (or their absence)
Learn from primary sources
Practice and explain it back
Queue backpressure
Producer 10k msg/s, consumer 2k msg/s. Queue depth grows 8k/s. When shed load — at depth 50k or consumer lag 60s?
Expected evidence: Alert on lag and depth; shed at SLA breach; scale consumers or throttle producer.
Open the interactive drill →Review prompts
- Why is 'exactly-once' delivery usually a myth, and what do you do instead?
Build evidence
Job queue with retries and DLQ
A background job queue with backoff, jitter, and a dead-letter queue.
- Retries with exponential backoff and jitter
- Poison messages routed to a DLQ
- Idempotent consumer handling
Synthesize: Distributed Systems
Reason about coordination, data placement, logs, durable workflows, consistency, and recovery under partial failure. Produce one working system, benchmark, or evidence-backed design that integrates the path.
- Implements or precisely models the core mechanisms from all three milestones
- Includes at least one injected failure or adversarial case and demonstrates recovery
- Reports quality, latency, resource, reliability, or usability measurements relevant to the domain
- Ships a concise architecture note explaining decisions, trade-offs, and remaining risks
Prerequisites
None assigned yet.