Chain-replicated object store
Writes flow head → middle → tail, strong reads come from the tail, and CRAQ lets clean replicas serve reads — with high/low water marks tracking commit progress.
What this design does
Chain replication gets you linearizability with a beautifully simple invariant: a write is committed exactly when it reaches the tail. CRAQ adds read throughput by letting any replica serve a read when its version is clean. This is the design inside many object stores and Azure Storage's stream layer — and the high-water-mark bookkeeping is the same trick Kafka uses.
The patterns it composes
- Chain replication — writes propagate head→tail; tail ack = committed
- CRAQ — clean replicas serve reads anywhere in the chain — read scaling without weakening consistency
- High / low water marks — HWM = committed frontier; LWM bounds what can be truncated
- Segmented log — each node persists the stream as fixed-size segments for cheap truncation
- Generation clock / epoch — chain reconfiguration bumps the epoch so zombies can't ack
Import it, attach your own numbers, and verify the design against failures — or read the engineering notes.