Consistency and Availability Tradeoffs

With one server, consistency is trivial. You write data, you read data — it's the same server, same memory, same disk. Now distribute that across ten servers in five data centers across three continents. A user writes to a server in Singapore. Half a second later, a user in Frankfurt reads. Do they see the new data? Maybe. That's the problem.

Consistency

In distributed systems, consistency means every read receives the most recent write. It doesn't matter which node you read from — you always get the same, up-to-date answer. All nodes see the same data at the same time.

This sounds like the obvious requirement. In practice it's expensive. To guarantee consistency, a write can't be confirmed until all nodes agree. That takes time — especially across data centers separated by thousands of miles.

Availability

Availability means every request receives a response. The system stays up and responsive even when some nodes fail or become unreachable. Users never see an error or timeout — they always get an answer, even if it might not be the most recent one.

High availability is also a requirement. Users who get errors leave.

The Tension

These two properties pull against each other. Here's why:

Imagine a network partition — Node A and Node B can't talk to each other. A user writes to Node A. Now a user reads from Node B. You have two options:

1. Return Node B's stale data — the system is available but inconsistent
2. Refuse to respond until Node B syncs with Node A — the system is consistent but temporarily unavailable

There is no option 3. This is the fundamental tradeoff. Every distributed system makes this choice, explicitly or implicitly.

Strong Consistency

Every read reflects the latest write. No exceptions, no staleness.

How it works: when a write comes in, it's not confirmed to the client until all (or a quorum of) nodes have acknowledged it. The write propagates synchronously. The client waits. Once confirmed, any subsequent read from any node returns the new value.

Tradeoffs:

• Higher write latency — you wait for replication before confirming
• Lower availability — if nodes can't sync, writes block
• Simpler application logic — you never have to handle stale reads

When you need it: anything involving money. Bank transfers, payment processing, inventory counts where overselling is catastrophic. You cannot show a user the wrong balance. The cost of being wrong is higher than the cost of being slow.

Eventual Consistency

The system will become consistent — all nodes will eventually converge on the same value — but reads might return stale data in the meantime.

How it works: writes are confirmed immediately on the receiving node. Replication happens asynchronously in the background. If you read a different node seconds later, you might see an older value. Eventually (usually milliseconds to seconds) all nodes catch up.

Tradeoffs:

• Lower write latency — confirm immediately, replicate later
• Higher availability — a node failure doesn't block writes
• Stale reads — application must tolerate seeing slightly old data

When it's fine: most things, actually. Social counters, search indexes, DNS, recommendation systems, shopping carts. Seeing 10,452 likes instead of 10,453 is a non-issue. The user doesn't notice and doesn't care.

Real-World Examples

Bank transfer — strong consistency. When you transfer £500, your balance must reflect that immediately everywhere. If the system showed your old balance on another device, you might try to spend money that's already gone. Banks use strongly consistent databases (or distributed transaction protocols) for this reason.

Twitter/X like counter — eventual consistency. A tweet with 2.3 million likes doesn't need to show the exact same count on every device at every moment. A few likes off is invisible to users. Twitter uses eventual consistency here and gains massive write throughput as a result.

DNS — eventual consistency. When you update a DNS record, it doesn't propagate everywhere instantly. Different resolvers around the world cache old values for minutes or hours. This is intentional — strong consistency for DNS would make the internet unbearably slow. The tradeoff is acceptable because stale DNS isn't catastrophic.

Shopping cart — eventual consistency (Amazon's famous choice). Amazon's Dynamo paper described their deliberate choice to prioritise availability for shopping carts. If two devices add items simultaneously and the cart briefly shows inconsistent state, that's fine — it reconciles. If the cart errored instead, customers would leave. They chose availability.

This Sets Up CAP Theorem

The tension between consistency and availability isn't just intuition — it was formalised mathematically. The CAP theorem states that a distributed system can guarantee at most two of three properties: Consistency, Availability, and Partition tolerance. Since network partitions are unavoidable in real distributed systems, the practical choice is always between consistency and availability.

The next lesson walks through CAP theorem formally, what it actually means in practice, and how real databases position themselves on this spectrum.

Key Takeaways

• Consistency — every read gets the latest write, all nodes agree
• Availability — every request gets a response, system stays up
• When a network partition occurs, you must choose one or the other — there is no both
• Strong consistency — higher latency, simpler logic, required for financial data
• Eventual consistency — lower latency, higher availability, fine for most social and content data
• Most real systems mix both: strongly consistent for critical paths, eventually consistent for everything else

---

Next: CAP Theorem — the formal proof behind this tradeoff, and how databases like Cassandra, DynamoDB, and Spanner each make the choice.