What latency and availability costs does a distributed system pay to offer linearizable reads and writes, and when would you deliberately choose not to pay them?

## Where the cost comes from Linearizability's cost comes directly from what it must guarantee: that every operation, no matter which physical node handles it, behaves as though there were only one copy of the data, updated instantly and visible everywhere the moment it changes. Delivering that illusion across physically separate machines connected by an unreliable, non-zero-latency network requires real coordination work on the **critical path of every operation**, not just occasionally. - **For writes**, this typically means either routing every write through a single leader that serializes all changes, or requiring a write to be acknowledged by a majority quorum of replicas via a consensus protocol like `Raft` or `Paxos` before it's considered committed. - **For reads**, naively answering from whichever replica happens to receive the request is not safe, because that replica might be lagging. A linearizable read instead has to either go to the leader, use a **leader lease** that proves no other leader could have taken over and made changes since the lease was granted, or perform a `Raft` "read index" round-trip that confirms the replica's state is at least as fresh as the latest committed write. ## The everyday, no-partition cost Each of these mechanisms adds a real network round trip — sometimes more than one — to the critical path of an operation that, without the guarantee, could have been answered instantly by the nearest replica. The latency penalty **compounds with physical distance**: a client in Europe talking to a `Raft` leader in the US pays a trans-Atlantic round trip on every linearizable read or write, whereas a locally-served, non-linearizable read pays essentially local latency. This is the everyday, no-partition cost, and it's why systems like Spanner, CockroachDB, or `etcd`, which offer linearizability, are measurably slower per-operation than a plain replicated cache that just serves whatever a local replica has. ## The partition cost The more dramatic cost shows up during a network partition, and this is where the **CAP theorem** stops being an abstract theorem and becomes an operational reality. If the network splits a cluster into two groups that can't talk to each other, a linearizable system's rule is unforgiving: any node that cannot confirm it's part of a majority, or cannot reach the current leader, must either refuse to serve requests or block until connectivity is restored, because answering on its own risks contradicting an operation that already completed on the other side of the partition. There is no configuration that avoids this trade-off during a genuine partition; CAP proves that a system cannot be simultaneously linearizable (consistent) and fully available while partitioned. Systems have to pick a side explicitly, and most real-world coordination services pick consistency over availability during a partition, deliberately going unavailable on the minority side rather than risking a wrong answer: - `etcd`; - `ZooKeeper`; - `Consul`. ## Scoping it narrowly The practical response to this cost is to scope linearizability narrowly rather than apply it universally. A system doesn't need every piece of data to be linearizable; it needs the specific operations where staleness or reordering would cause real harm to be linearizable, and everything else can be served from local, possibly-stale replicas for speed and availability. ### Relax the guarantee - a shopping cart; - a social media feed's like-count; - a cached product description. These tolerate a stale read for a few hundred milliseconds without any real consequence, so serving them from the nearest replica with eventual or causal consistency is the right trade: lower latency, higher availability, and no correctness cost that matters to the business. ### Pay for the guarantee - a bank account balance check immediately before authorizing a withdrawal; - a distributed lock's current holder; - a unique idempotency key; - an inventory count at the exact moment of overselling risk. These are exactly the operations where a stale or reordered answer produces a real, sometimes financial or safety-critical, bug, and that's where paying for linearizability, even at the cost of extra latency and reduced availability during partitions, is worth it. ## Where it shows up A concrete example of this scoping in practice: a large e-commerce platform typically keeps its product catalog and browsing data on a fast, eventually consistent, globally replicated cache, because a customer seeing a price that's a few seconds stale is a non-issue, while it routes the actual checkout/inventory-decrement step through a linearizable, quorum-backed store, because overselling the last unit of a limited item to two simultaneous buyers is a real financial and reputational cost. The engineering skill being tested here isn't "always use linearizability" or "never use it" — it's correctly identifying which handful of operations in a system actually need the real-time, single-copy guarantee, and deliberately choosing weaker, cheaper consistency for everything else.