Topic 10.13
Delivery Semantics
In one line
At-most-once, at-least-once, exactly-once — the contract between producer and consumer, and where the lies live.
Think of it like this
Promising to deliver a birthday gift 'at most once' (it might not arrive), 'at least once' (it will arrive, but maybe twice if the courier is confused), or 'exactly once' (guaranteed, exactly one gift, no more no less — the hardest promise to keep).
Key ideas
- 01
At-most-once: message may be lost (ack before store) — used when loss beats duplicate (dismissable telemetry).
- 02
At-least-once: message delivered until acked, duplicates possible — the default for most business pipelines.
- 03
Exactly-once: not actually possible across a network without idempotency somewhere — it's at-least-once + idempotent processing.
- 04
Where duplicates come from: producer retries, consumer rebalance, broker re-delivery after unclear commit.
- 05
The engineer's translation: 'exactly-once' = dedupe by natural key at the sink (eventId/orderId unique upsert).
- 06
Interview: 'I design for at-least-once and make every consumer idempotent — duplicates stop being a bug'.
Java / Spring map
- →
De-duplicate via DB unique index on event_id inside the consumer transaction; Kafka Transactions for producer+consumer provenance (rarely needed).
Code & diagrams
Explain without notes
Show the exact interleaving where 'at-least-once' produces a double refund if the consumer isn't idempotent.
Practice
Design the idempotency key + unique index for a payment events consumer.
Trade-offs
- ↔
Idempotency machinery (dedupe tables, natural keys) is the honest cost of pretending to be exactly-once.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I always convert 'exactly-once' into 'at-least-once + idempotency' in design conversations.