Consistency & Reconciliation

Why consistency matters

Distributed systems trade off latency, availability, and consistency. Different applications need different guarantees.

Models in one line

• Linearizable: reads see the latest real-time write.
• Causal: reads respect happens-before dependencies.
• Eventual: replicas converge over time, but reads can be stale.

Staleness windows

Bounded staleness puts a time limit on how far behind a read can be. You can reason about staleness using replication lag and write times.

Session guarantees

Clients often want per-session guarantees like:

• Read-your-writes
• Monotonic reads
• Monotonic writes
• Writes-follow-reads

Anti-entropy & reconciliation

Replicas exchange metadata (like vector clocks) to detect:

• one replica dominates the other
• or concurrent updates that need resolution

Common strategies:

• Vector clock merge (detect conflicts)
• Last-write-wins (choose latest timestamp)

What you will build

• Strongest consistency classification
• Bounded staleness read selection
• Anti-entropy reconciliation (VC vs LWW)
• Multi-version read repair (vector clocks)
• Session guarantees checker