Topic 11.15
Idempotency (again, now at fleet scale)
In one line
Idempotency applied to whole services: keys per logical operation, dedupe stores, and safe replays.
Think of it like this
The same doorbell button — pressing it once or five times in a row nervously still just rings the bell once as far as anyone inside is concerned.
Key ideas
- 01
Fleet-scale retries (LB retry, consumer rebalance, saga step retry) multiply duplicates — idempotency is the fleet's immune system.
- 02
Per-operation idempotency keys from the client; per-event natural keys from the producer.
- 03
Implementation: unique index on (idempotencyKey, serviceId) + return the memoized previous outcome on conflict.
- 04
Distributed dedupe: Redis SETNX + DB row (for real guarantees), or a dedupe table in the service's own DB.
- 05
Saga steps re-run safe: each step idempotent → saga retry is a no-op rather than double-charge.
- 06
Interview: 'every service exposes idempotent operations; every consumer dedupes by event key — duplicate safety is a system property'.
Java / Spring map
- →
IdempotencyFilter + repository with unique key; Kafka consumer upsert by eventId.
Explain without notes
Show the exact duplicate path an LB retry produces — and where the unique index stops it.
Practice
Design the idempotency table + response memoization for the checkout endpoint.
Trade-offs
- ↔
Dedupe lookups are the price; they're cheaper than the double-charge incident review.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
Idempotency-by-key covers every write that a retry can reach — which is all of them.