Consistency Spectrum explained in Distributed Systems

Background

You might have heard about CAP & PACELC theorems in Distributed System Designs. Put simply, CAP suggests to prioritize which system capability - either consistency(C) or availability(A) to prioritize under network partitions(P) as they are inevitable in a distributed system architecture. PACELC takes it a notch further to prioritize Latency(L) or Consistency(C) if there isn’t a network partitioning scenario. Feel free to read further on this separately.

However, upon reading about these theorems, I stumbled upon the kinds of Consistency flavors that can be achieved in Distributed Systems. Here is an attempt to simplify the concepts it for better understanding

Setup

Imagine Ana, Ben and Cara each keep their own notebook copy of a shared grocery list. A messenger runs between them to keep syncing changes. This is an hypothetical distributed system scenario - where each notebook can be thought of an replica, the messenger is the network replication and every consistency level is just a rule about what the messenger promises to keep the grocery list in sync.

Consistency Spectrum Levels

Now let’s walk down that list one level at a time, with the notebook story attached to each.

1. Eventual — Ana writes “milk” in her notebook. Right now, Ben’s and Cara’s notebooks still say the old list. There’s no promise about when the messenger updates them — only that if everyone stops writing, all three notebooks will eventually match. This is the cheapest option because nobody has to wait for anybody.
2. Monotonic reads — Say you always check Ben’s notebook specifically. The promise here is narrower: once you’ve seen “milk” in Ben’s notebook, you will never later see a version of it without milk. Your view only moves forward in time, even if it’s behind.
3. Read-your-writes — You’re Ana, and you wrote “milk” yourself. This guarantees that whenever you check the list again, your own addition is always there, even if Ben and Cara haven’t gotten the memo yet. No amnesia about your own actions.
4. Causal — Ana writes “milk,” then tells Cara “I added milk, so add eggs for the custard.” Cara writes “eggs.” Causal consistency guarantees anyone who sees “eggs” also sees “milk” first — cause before effect. But if Ben separately and independently adds “bread,” that item has no causal link to the other two, so different people might see it in a different position. Real systems: replies always appear after the comment they’re replying to.
5. Sequential — Now imagine all three friends have to agree on one single story of the order everything was written — as if there’s really just one notebook being passed around. Everyone recites the exact same sequence: “milk, eggs, bread.” But that agreed-on order doesn’t have to match the real-world clock time each item was actually written — it just has to be the same for everyone.
6. Linearizable — Same as sequential, but now that shared order also has to match real, physical clock time. If milk was genuinely written before bread happened, everyone must see it in that exact order, as if there were only ever one notebook the whole time. This is the strongest and priciest, usually because you need one “boss” replica to confirm every write before anyone is allowed to read it.

NOTE: That sequential-vs-linearizable line is the one people usually get wrong, so here’s the scenario that makes it click

That’s the whole gap between the two: sequential just needs a consistent story everyone agrees on; linearizable needs the true story, timestamped like it really happened.

How each level is used in real systems

• Eventual: DNS, CDN caches, S3 (older consistency model), most “like” counters
• Monotonic reads: session-pinned reads in many NoSQL setups
• Read-your-writes: your own post appearing in your own feed immediately
• Causal: comment/reply threads, collaborative editors
• Sequential: some replicated state machines / logs where global order matters but not wall-clock precision
• Linearizable: bank balances, inventory counts, distributed locks, leader election

Why cost goes up as guarantees go up

• Eventual needs zero coordination — replicas gossip whenever they feel like it.
• Monotonic reads and read-your-writes just need to track which replica or version a reader last saw (a session token, a version vector).
• Causal needs to track dependencies between writes (vector clocks).
• Sequential needs everyone to agree on one ordering, which usually means routing writes through a sequencer.
• Linearizable needs a write to be confirmed by a leader in real time before anyone can safely read it — that round-trip is where the latency cost comes from.

Conclusion

So the real question is “how much are you willing to pay in latency to avoid surprising a user?” Weak guarantees are fast and cheap but can show stale or out-of-order data; strong guarantees cost real coordination time but behave the way your intuition expects a single computer to behave.