Eventual consistency is the default in distributed systems because it's cheap. But some operations genuinely cannot tolerate stale reads — and recognizing them is what separates engineers who debug overdraft bugs at 3am from those who don't.

What strong consistency actually means: every read sees the most recent write, regardless of which node serves it. The system behaves as if there's one copy of the data, even when there are five. Formally, this is linearizability: operations appear to take effect atomically at some point between their invocation and completion.

The price you pay: coordination. Before acknowledging a write, the system must ensure no other node will serve a stale read. That means consensus protocols (Raft, Paxos), quorum reads and writes, or a single leader funneling all traffic. Every one of those costs latency and availability.

Real-world example — bank transfers: Alice has $100. She initiates two simultaneous $80 withdrawals from different ATMs. With eventual consistency, both ATMs might read $100, both succeed, and Alice ends up at -$60. With strong consistency, the second read sees the first write's effect — the second withdrawal fails. This is non-negotiable for financial ledgers, inventory in flash sales, and unique-username registration.

How to get it:

• Single-leader replication with synchronous followers — writes acknowledged only after replicas confirm. Postgres synchronous_commit, MySQL semi-sync.
• Quorum systems where R + W > N. If you have 5 replicas and require 3 to ack writes and 3 to respond to reads, any read overlaps with the last write by at least one node.
• Consensus-backed stores like etcd, Spanner, CockroachDB — Raft or TrueTime under the hood.

The quorum math: with N=5, W=3, R=3, you can tolerate 2 node failures and still serve strongly consistent reads. With N=5, W=1, R=1, you tolerate 4 failures but get eventual consistency. The tradeoff is explicit and tunable per operation.

Rule of thumb: if the cost of serving stale data is greater than the cost of returning an error or adding 20-50ms of latency, you need strong consistency. Money, identity, locks, leadership — yes. Like counts, view counters, recommendation scores — no.

The trap: engineers reach for strong consistency by default because it's easier to reason about. But linearizability across a multi-region deployment costs you 100-300ms per write minimum, plus availability during partitions. Use it surgically — wrap the truly critical operations in it, and let everything else ride on eventual consistency.