In this chapter
We'll meet PACELC as the honest extension of CAP — even with no partition, a distributed system constantly trades latency against consistency on every write — and see strong vs. eventual consistency as two real, opposite answers to that constant, everyday choice, not just a during-an-outage one.
The Problem in Real Life
Mike has one honest follow-up, once the partition itself is fixed and the link is back: does this trade-off go away now? Everything's reconnected. Surely the hard choice was only ever a during-the-outage problem.
Sarah has to tell him no — quieter, but the same real choice never actually stops. It's just less dramatic on an ordinary Tuesday than it was during the sale.
The partition made it obvious. It didn't create the trade-off. That was always there.
Sarah
A Choice Only During Outages vs. A Choice, Constantly
PACELC: the choice that never fully stops
Partition or not, a system is always choosing — Availability vs. Consistency during one, Latency vs. Consistency otherwise.
Strong consistency: correct, always slower
Every write waits for every relevant replica to confirm — genuinely correct, genuinely never the fastest option.
Eventual consistency: fast, briefly stale
A write counts as done the instant one replica has it — fast, with a real, possible stale-read window, partition or not.
No universal right answer
A payment leans strong; a "likes" count leans eventual — the right setting depends on what being wrong actually costs.
PACELC & Consistency Models
PACELC is the honest extension of CAP that answers Mike's exact question. It reads almost like a sentence: if there's a Partition, choose Availability or Consistency (CAP's own trade-off) — else (normal operation, no partition happening at all), choose Latency or Consistency instead. The second half is the real, quiet part CAP alone never mentions: even with every region perfectly reachable, a distributed system still has to decide, on every single write, how much confirmation to wait for before calling that write done.
- Strong consistency, chosen constantly (not just during a partition): every write waits for confirmation from every relevant replica before it's considered successful. Correct, always — and genuinely slower, every single time, because a write is only as fast as its slowest required replica's own confirmation.
- Eventual consistency, chosen constantly: a write is considered done as soon as it lands on one replica, with the promise (not the guarantee, until it actually happens) that the others will catch up shortly after. Fast, always — and genuinely capable of returning a stale answer to a read that happens to hit a replica that hasn't caught up yet, with zero partition required for that to happen.
The Same Trade-Off, On an Ordinary Day
A write happens
No partition. Every region is reachable right now.
Wait for every replica to confirm?
Strong consistency — correct, slower, every time
Confirm as soon as one replica has it?
Eventual consistency — fast, every time, briefly stale elsewhere
This is precisely availability vs. consistency, generalized past the dramatic, once-in-a-sale partition into an everyday, every-write reality. GreenMart's own stock count, on a perfectly ordinary afternoon with zero network trouble at all, is still making this exact choice on every single sale — just usually invisibly, because the gap between "one replica confirmed" and "every replica confirmed" is normally milliseconds, not the several minutes a real partition stretches it into.
This is also the honest reason there's no single, universally correct setting to leave a distributed system on forever. A payment system reasonably leans toward strong consistency on every write, accepting the latency cost, because a wrong answer is expensive. A "likes" counter on a social post reasonably leans toward eventual consistency, accepting a few seconds of a slightly-stale number, because speed matters more than a temporarily-off count nobody will ever notice. GreenMart's own stock count sits somewhere between the two — and this Act's checkpoint later asks exactly where, on purpose, rather than by accident.
Key Takeaway
PACELC's real contribution is naming the trade-off CAP leaves out: even with no partition happening at all, a distributed system is still constantly choosing between latency and consistency, on every write. GreenMart's incident made the Consistency-vs-Availability half of this dramatic and visible for a few minutes — the Latency-vs-Consistency half was quietly running the whole time, on every ordinary sale, before and after.
Why This Matters
This is the real, everyday version of the choice this Act's incident made dramatic — every remaining chapter's own mechanisms (quorum, replication topology) are really about deciding, deliberately, where on this constant trade-off GreenMart actually wants to sit, for each specific kind of data.
GreenMart now knows this trade-off never fully goes away, even on a perfectly ordinary day with no partition at all. How many real copies actually have to hold the data, and who's responsible for keeping them synchronized, is exactly where the next chapter goes.