Consistency Is a Per-Operation Decision

The spectrum is a dial, not a switch

Between “every read sees the latest write” and “reads see something, eventually” lies a graded spectrum, and each stop buys a guarantee at a price. The mistake most teams make is treating it as a binary they set once, globally, in a config file — when the right mental model is a dial they turn per endpoint. Sweep it:

Notice what happens around the middle. Linearizable is what people mean when they say “strongly consistent”: one global, real-time order, at the cost of a coordination round trip and unavailability during a partition. You need it far less than you think — for the username uniqueness check, the lock, the balance gate before a withdrawal. Eventual is the cheap end: perfect for a like counter, lethal for the username your user just set. The two stops that quietly run most user-facing software live in between.

CAP is a footnote. PACELC is the bill you pay daily.

Everyone quotes CAP — under a network Partition, choose Availability or Consistency. True, and almost irrelevant to your day, because real partitions are rare. CAP describes a decision you make for a few seconds a year. It says nothing about the cost you pay on every request when the network is perfectly healthy.

PACELC completes it, and it’s the version worth memorizing: if Partition, then A or C; Else, then L or C. The else clause is the one that bills you continuously. Even with a flawless network, stronger consistency costs latency — a read that must confirm it has the newest value has to talk to a quorum or the leader, and that round trip is on your p99 forever. The real architectural question isn’t “what do we do during a partition?” It’s “what latency are we paying for consistency right now, and is this operation worth it?”

Building read-your-writes without going linearizable

Here is the core of the session router: a per-session high-water mark (the newest version this session has observed) and a read that refuses any replica too stale to honor it, falling back to the leader. No global coordination — just one session’s freshness floor.

1read(sessionId: string, key: string): ReadResult {
2  const hw = this.highWater.get(sessionId) ?? 0
3 
4  // only serve from a replica fresh enough to honor what this session saw
5  const replica = this.replicas.find((r) => r.appliedVersion >= hw)
6  const [result, servedBy] = replica
7    ? [replica.get(key), replica.id]
8    : [this.leader.latest(key), "leader"]   // nobody's fresh -> the leader is
9 
10  const version = result?.version ?? 0
11  // a RYW / monotonic-read violation IS exactly: handing back something
12  // older than this session already observed.
13  const staleViolation = version < hw
14  if (result) this.bump(sessionId, version)
15  return { value: result?.value, version, servedBy, staleViolation }
16}

What this sounds like in an interview

Exercises

1write(sessionId: string, key: string, value: string): number {
2  // optimistically record that we'll have observed this write
3  const nextVersion = this.leader.peekNextVersion()
4  this.bump(sessionId, nextVersion)   // <- bump BEFORE the write commits
5  const version = this.leader.write(key, value)
6  return version
7}