Delivery Guarantees: At-Least-Once, Exactly-Once, and Idempotency
Once messages can be retried, a new problem appears: a payment could be charged twice, or lost entirely. This piece is about the three promises a messaging system can make (at-most-once, at-least-once, exactly-once), why exactly-once is really achieved by making the work idempotent, and why order matters. It closes the messaging arc.
A from-the-ground-up look at delivery guarantees, the last piece of the messaging arc. The three promises a system can make: at-most-once (a message may be lost but never duplicated), at-least-once (never lost but may arrive more than once), and exactly-once (once and only once). Why real systems run at-least-once and reach exactly-once in practice by making each operation idempotent, so a retried request has no extra effect, the way a Stripe idempotency key prevents a double charge. Why ordering matters, and what Amazon SQS standard and FIFO queues, Apache Kafka, and application-level idempotency keys actually guarantee. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
- System Design
