Queues, Streams, Eventing
Delivery guarantees: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before opening the model answer — the effort of recall is what makes the impossibility proof and the production patterns stick together.
Reconstruct the unit’s spine without looking back: why exactly-once delivery is impossible, where duplicates come from, how the consumer makes them harmless, and which broker-side tools cover which gap.
- 01State the Two Generals' Problem and explain the asymmetry that makes exactly-once processing achievable even though exactly-once delivery is not.
- 02Name the three failure legs and say which produces most production duplicates and why.
- 03Why must the dedup INSERT and the side effect commit in one transaction, and why INSERT first?
- 04What is the SQS visibility-timeout rule of thumb, and what resets on redelivery?
- 05What do Kafka's idempotent producer and transactions each cover, and what do they NOT cover?
- 06What is the dual-write problem and how does the outbox pattern solve it?
If you could reconstruct each answer from memory, you hold the unit’s spine: Two Generals makes exactly-once delivery impossible, so production runs at-least-once and enforces effectively-once in the consumer. Duplicates concentrate at Leg 3; an INSERT-first transactional dedup plus an Idempotency-Key for external calls makes them harmless. Kafka’s idempotent producer and transactions only harden the within-Kafka path, SQS visibility timeout must be sized to ~6x processing, and the outbox pattern closes the producer-side dual-write. The recurring lesson: broker guarantees are necessary but never sufficient — correctness lives in the consumer and the operational discipline.