Consistency Model Explorer
What is a consistency model?
A consistency model is a precise promise about which values a client may observe when writes, reads, replication, and failures overlap.
Step 1
Model
Choose the promised model, write acknowledgement, read route, session protection, operation timing, and a failure or recovery history.
Step 2
Observe
Inspect replica values, trace every operation, and see whether the observed history satisfies or disproves the promise.
Step 3
Challenge
Force a stale read, then add read-your-writes protection. Compare that result with a network partition, concurrent writes, and three recovery policies.
Make the guarantee prove itself
Promise a consistency model, configure the read and write protocol, then inject a history that can confirm or disprove the claim.
3. Failure injection
Challenge the healthy path
User-visible outcome
The UI appears to undo the save
Client A saved V1, refreshed, and saw V0. A user may retry and create duplicate work.
Observed read
V0
Observed system
Replica state at read time
Primary region
Replica A
Write coordinator
Stored V1 at 100 ms
Primary region
Replica B
Quorum peer
V1 visible at 980 ms
Remote region
Replica C
Client A local read
Still on V0; V1 arrives at 1,700 ms
Write reply
130 ms
Read begins
500 ms
Replica C catches up
1,700 ms
Operation timeline
Trace the observed history
0 ms
Client A
Previous read
Client A observed V0.
100 ms
Client A
Write V1
Client A sends V1 to Replica A.
120 ms
Replica A
Store V1
Replica A starts replication.
500 ms
Client A
Read returns V0
The nearest replica responds before V1 arrives.
980 ms
Replica B
Apply V1
Replica B advances from V0 to V1.
1,700 ms
Replica C
Apply V1
Replica C catches up to V1.
Contract verdicts
Test each guarantee against this history
Promised contract
Read-your-writes
Client A completed V1 and then observed V0 in the same session.
Forced stale read
What changed and why
Client observation
The nearest replica responds before V1 arrives.
Design consequence
A consistency label is only valid if every allowed history satisfies its promise. Change the route, acknowledgement, timing, or session token and compare the same fault again.