Topic 13.14
Data Consistency Patterns
In one line
The pattern library you choose from per flow: outbox, saga, event sourcing, CQRS, TTL caches, read-your-writes, idempotency.
Think of it like this
Different 'levels of trust' you can put in an updated notice board — from 'I saw it update myself, live' (strong) to 'someone told me it probably updated by now' (eventual) — and knowing which situations need which level.
Key ideas
- 01
Mental map: cross-store atomicity → outbox (11.14); cross-service flows → saga (11.13); audit/replay → event sourcing; read skew → CQRS; staleness control → TTL caches + cache fallbacks.
- 02
Duplicate safety → idempotency keys (10.16/11.15); fresh own-writes → read-your-writes routing.
- 03
Exact agreement across many nodes → consensus (Raft via etcd) — the heaviest hammer, used sparingly.
- 04
Sequence: define the invariant → pick the cheapest pattern that preserves it → escalate only when it can't.
- 05
Every pattern is 'accept some X to get Y' — the deliverable is the pattern + the price you named.
- 06
Interviews: 'order placement = local tx + outbox + saga for payment/inventory' is the sentence that ties the syllabus together.
Explain without notes
Map each pattern to a failure it prevents: (outbox→lost event, saga→partial order, idempotency→duplicate, r.y.w→stale own-post).
Practice
For 'money transfer between two services', pick the pattern set and justify the 2PC rejection.
Trade-offs
- ↔
Patterns are taxes with benefits — the craft is paying only the ones the invariant demands.
Completion checklist
I can choose a consistency pattern per flow from a stated invariant.