CONCEPT Cited by 1 source
Strict eventual consistency¶
Strict eventual consistency is a refinement of eventual consistency that guarantees convergence to a deterministic state for any quiescent system, given any combination of:
- partial-failure-during-write (system absorbs the failure and retries until the write lands);
- arbitrary message reordering across replicas (replicas converge regardless of receive order);
- arbitrary write hedging or retries (idempotent writes converge to the same result);
- concurrent updates and deletes against the same key (a deterministic conflict-resolution rule picks the winner — typically last-write-wins via timestamped idempotency tokens).
Plain eventual consistency only guarantees that some value will be read once writes stop; strict eventual consistency additionally guarantees the same value will be read on every replica.
Mechanism stack¶
A practical strict-EC system layers three primitives:
- Idempotent writes via tokens with timestamps. Hedged or retried writes that re-arrive under the same logical operation collapse to one effect at the storage layer.
- Deterministic conflict resolution — typically LWW keyed off the token's timestamp. Concurrent updates resolve identically across replicas.
- Entropy repair — a durable retry mechanism (Kafka, anti-entropy gossip, Merkle trees) that rediscovers writes that failed partway and pushes them to convergence.
If any layer is missing, the system can be eventually consistent but not strictly: replicas might converge to different values (missing layer 2), drift indefinitely (missing layer 3), or double-apply hedged writes (missing layer 1).
Netflix Graph Abstraction as the canonical instance¶
The [[sources/2026-05-29-netflix-high-throughput-graph-abstraction-at-netflix-part-i|2026-05-29 Part-I post]] discloses all three primitives by name:
"The connected nature of the data, low-latency API requirements, and the need to handle intermittent failures have led to design choices that enforce strict eventual consistency across multiple regions."
| Primitive | Mechanism in Netflix Graph Abstraction |
|---|---|
| Idempotent writes | timestamped idempotency tokens inherited from KV Abstraction |
| Conflict resolution | LWW at the KV-storage layer |
| Entropy repair | Kafka-driven retry pipeline (patterns/kafka-entropy-repair-for-multi-namespace-writes) |
Multi-region replication on the underlying KV + EVCache layers is asynchronous; strict-EC is therefore the property the graph layer inherits and depends on. The post's asynchronous cascade-delete correctness argument is the most striking application: a delete race against concurrent updates is correct only if LWW gives the delete-with-higher-timestamp the win, which is a strict-EC property, not a plain-EC one.
Strict-EC vs adjacent guarantees¶
| Guarantee | What it adds over strict-EC |
|---|---|
| Read-after-write (your-own-writes) | a client that wrote sees its own write next |
| Monotonic reads | a client never sees an earlier value than they previously saw |
| Causal consistency | reads respect happens-before from any client's view |
| Linearizability | every operation appears to happen at a single instant; cross-client ordering preserved |
Strict-EC is weaker than all of these — it makes no per- client ordering claims. A client may observe earlier values on a later read against a different replica. The guarantee it adds over plain EC is deterministic convergence.
When strict-EC is the right choice¶
- Cross-region writes where synchronous quorum would blow the latency budget.
- Multi-namespace writes where distributed transactions are unavailable or too expensive.
- High-fanout cascades (graph node delete touching millions of edges) where synchronous propagation is impractical.
- Data shapes that tolerate per-client ordering ambiguity but require eventual deterministic state — graphs, counters, service-topology metadata.
When strict-EC is insufficient¶
- Per-user money movement (need linearizability or 2PC).
- Inventory allocation with hard limits (need linearizability or a coordinator).
- Tail-of-write read scenarios where the application cannot tolerate seeing an old value (need read-your-writes at minimum).
Seen in¶
- sources/2026-05-29-netflix-high-throughput-graph-abstraction-at-netflix-part-i — canonical wiki disclosure: "design choices that enforce strict eventual consistency across multiple regions". Three named mechanisms: LWW via idempotency tokens; Kafka entropy repair across multi-namespace writes; asynchronous cascade delete made correct by LWW.