04 — Consistency Patterns: Strong, Weak, and Eventual

"Just let the database sort it" was my consistency strategy, which made every surprising read feel like a bug. Writing it down turned a vague intuition into a contract I can reason about: a consistency pattern is a guarantee about how soon after a write the next read will see it — and the cost climbs steeply with the strength of the guarantee. [1] The whole map is just three contracts.

The framing that clicked is that "consistency" is not a single dial. It is a _spectrum of promises_ the store makes to readers about visibility of writes. Strong consistency is the strictest promise (instant, everywhere), weak consistency is the loosest (no promise at all), and eventual consistency sits in the middle as the practical default for distributed systems that need to stay available [1]. Once I saw the three as points on one spectrum, picking one became a cost/benefit decision instead of a guess.

The three contracts

The roadmap collapses the field to three patterns, and that is genuinely most of what I need day to day [1]:

• Strong consistency. After a write, any subsequent read — from any replica — immediately reflects it. The data is replicated synchronously, so every copy is updated at the same time before the write is acknowledged [1]. Cost: the write blocks until all replicas agree, so latency is higher and availability drops if a replica is unreachable. This is the CP side of CAP.
• Weak consistency. After a write, a subsequent read is _not_ guaranteed to reflect it. The read may or may not see the recent change [1]. This is the loosest contract — best effort, no promises. It is rarely chosen explicitly; it is the default of systems that make no consistency claim at all.
• Eventual consistency. A specific, weaker form of strong consistency (and the most common flavor of weak). After a write, it will _eventually_ be visible to any subsequent read — the data is replicated asynchronously, so all copies converge once propagation finishes [1]. Cost: during the convergence window, reads can be stale, but writes are fast and the system stays available. This is the AP side of CAP, and the workhorse of real-world distributed stores.

The cost ladder

The way of thinking that made these click is a cost ladder. Going up the ladder — weak → eventual → strong — buys stronger read guarantees and pays for them with write latency and reduced availability under failures:

• Weak costs nothing in latency but promises nothing.
• Eventual costs a convergence window (milliseconds to seconds) in exchange for fast writes and high availability.
• Strong costs synchronous coordination on every write, which is why truly strong-consistency stores are slower and harder to keep up under partition.

How I use this

I treat the choice as a per-data-type question, same as the CAP decision it underpins. For anything where a stale read causes real harm — a balance, a stock level, an auth token revocation — I pay for strong consistency and accept the slower writes. For everything else — feeds, counts, search indexes, denormalized read models — eventual consistency is the default, because fast writes and uptime matter more than perfect freshness, and a few seconds of staleness is invisible to the user. The discipline is to stop defaulting to "whatever the database does" and instead name the contract each dataset actually needs.

References

[1] cs.fyi, "Consistency patterns in distributed systems (weak, strong, eventual)," 2021. [Online]. Available: https://cs.fyi/guide/consistency-patterns-week-strong-eventual/

[2] D. Martin, "Eventual consistency," system-design-primer (open source), 2024. [Online]. Available: https://github.com/donnemartin/system-design-primer#eventual-consistency

[3] "CAP theorem revisited," robertgreiner.com, 2014. [Online]. Available: https://robertgreiner.com/cap-theorem-revisited/

[4] "A plain english introduction to CAP theorem," ksat.me. [Online]. Available: http://ksat.me/a-plain-english-introduction-to-cap-theorem