Topic 10.16
Idempotency
In one line
The property that makes retries, replays and at-least-once safe: same request → same result, every time.
Think of it like this
Pressing an elevator's 'call' button five times because you're impatient. The elevator doesn't come five times faster or send five elevators — pressing it repeatedly has the exact same effect as pressing it once.
Key ideas
- 01
Definition: applying an operation multiple times equals applying it once.
- 02
Where you need it: payment charges, refunds, order creation, event consumers, webhook handlers.
- 03
Mechanisms: idempotency keys (client-generated) + unique index; natural key upserts; versioned state machines.
- 04
Key design: key generated per logical operation (not retry) — a client retry sends the SAME key.
- 05
The storage-level guarantee: INSERT with unique index, on conflict return the previous result.
- 06
Interview: 'idempotency is the contract that lets me retry anything, any time, without asking permission'.
Java / Spring map
- →
Full idempotent payment code lives in phase-4 → payment-system-lld.
Explain without notes
Show how upsert-by-natural-key makes a Kafka consumer idempotent across a rebalance.
Practice
Design the idempotency table for 'refund order' including the unique key and the response memoization.
Trade-offs
- ↔
Idempotency costs a dedupe lookup per operation — cheap insurance against the expensive duplicate.
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 design every write path that can be retried to be idempotent by key or natural key.