Availability vs Consistency
Availability means every request gets a response. Consistency means every read sees the latest write. In distributed systems, you often have to choose between them — especially during network partitions. This trade-off is the heart of CAP theorem.
How it works
Availability means every non-failed node returns a response (not an error or timeout) for every request. The response might be stale, but it's not an error.
Consistency (in the CAP sense, i.e., linearizability) means every read sees the most recent write, as if there were a single copy of the data.
In a single-machine system, you get both for free — there's only one copy. In a distributed system, when the network between nodes fails (a partition), you must choose: refuse to respond (lose availability) or respond with possibly-stale data (lose consistency).
Real-world examples make this concrete:
- Bank balance: must be consistent. If you transfer $100, a subsequent read MUST reflect it. If the system is partitioned, the bank refuses the read (unavailable) rather than showing a wrong balance.
- Social media feed: can be eventually consistent. If you post a tweet and a follower's feed updates 5 seconds later, that's fine. The system stays available during partitions.
- Shopping cart: must be consistent. You can't show a wrong item count — users would lose trust.
- Like counter: can be eventually consistent. '1,234 likes' vs '1,235 likes' doesn't matter for a few seconds.
Ask: 'What happens if the user sees stale data?'
- If it causes financial loss, data corruption, or safety issues → choose consistency.
- If it causes minor inconvenience or temporary confusion → choose availability.
- Most systems have mixed requirements: consistent for writes (payments), eventually consistent for reads (feeds). This is the common pattern.
CAP theorem (next lesson) formalizes this trade-off during partitions. But even without partitions, there's a latency-vs-consistency trade-off: stronger consistency requires more coordination (quorum reads/writes, consensus rounds), which adds latency. This is captured by PACELC: during a Partition, choose A or C; Else (normal operation), choose L (latency) or C.
You're designing a ride-sharing app's driver location tracker. Drivers broadcast their location every 4 seconds. Should the tracker prioritize consistency or availability?
Pick one answer.
Your payment system processes credit card charges. During a network partition between your primary DB and the replica, a user checks their balance. What should happen?
Pick one answer.
Tunable consistency — most production systems are mixed. Real distributed databases don't make you pick one side of CAP for the whole system. They let you choose per operation based on the workload.
In DynamoDB, every read/write specifies a consistency level:
EventuallyConsistentRead(default, 1 read capacity unit per 4KB): reads from any replica, may be stale, but cheapest and most available.StronglyConsistentRead(2 read capacity units per 4KB): reads from the leader, always returns the latest write, but fails if the leader is unreachable (CP behavior).
In Cassandra, every query specifies CONSISTENCY LEVEL:
ONE— read from any one replica (AP, fastest, may be stale).QUORUM— read from a majority of replicas (tunable CP, slower, strongly consistent if writes are also QUORUM).ALL— read from every replica (CP, slowest, fails if any replica is down).
This is the right design: a banking app uses strongly consistent reads for balances and eventually consistent reads for transaction history thumbnails. A social feed uses eventually consistent reads everywhere. The database doesn't force you into one bucket — the application code picks per operation, and the cost (latency, capacity, availability) is paid per operation.
Bank vs social feed — same database, different choices.
| Aspect | Bank ledger | Social feed |
|---|---|---|
| Critical data | account balance, transaction history | posts, likes, comments |
| Cost of stale read | overdraft, financial loss, disputes | user sees post 5s late |
| Cost of unavailability | can't process payments, revenue loss | user refreshes, minor annoyance |
| CAP choice | CP (consistency > availability) | AP (availability > consistency) |
| Consistency level | strong (linearizable) | eventual |
| Replication | synchronous, quorum writes | asynchronous, accept on any replica |
| Latency cost | higher (must coordinate) | lower (no coordination) |
| Real example | Spanner for AdWords billing | Cassandra for Instagram feed |
Both can run on the same physical infrastructure — the difference is the consistency policy chosen per operation. Modern distributed databases (DynamoDB, Spanner, CockroachDB, Cassandra) let you tune per operation. This is why 'AP vs CP' is the wrong question at the database level — the right question is 'per operation, which consistency level do you need?'
The architect's job is to identify, for each piece of data, what failure costs more: stale reads (favor CP) or unavailability (favor AP). Most systems have both: payment state is CP, social feed state is AP, in the same database cluster.
DynamoDB lets you set ConsistentRead=true per request. Strongly consistent reads cost 2x the read capacity units (RCU) of eventually consistent reads, and they fail if the leader replica is unreachable. Eventually consistent reads are cheaper, faster, and always available — but may return stale data. The DynamoDB team's recommendation is explicit: use strongly consistent reads for writes that other parts of the system will immediately read back (e.g., write an order, then read it back to confirm) — use eventually consistent reads for everything else (e.g., listing all orders, showing a dashboard). This is a per-operation, not per-table, decision — and it's why DynamoDB can power both Amazon's shopping cart (must be consistent) and its recommendation feed (can be eventually consistent) on the same infrastructure.
You're building an e-commerce checkout flow. Which data should use strongly consistent reads/writes, and which can be eventually consistent?
Pick one answer.
Likes are integer counters. The post is viral for ~1 hour. Users don't care if the displayed count is off by a few hundred for a few seconds. But the final count must be correct (advertisers pay based on engagement).
You're designing a distributed counter for 'likes' on a viral post. Expected: 10,000 likes/sec at peak on a single popular post. Choose between (a) strongly consistent (CP) writes via Cassandra QUORUM, or (b) eventually consistent (AP) writes via Cassandra ONE with read-repair. Justify.
Engineering mental model
Mental model. Think of Availability vs Consistency as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Availability vs Consistency mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Availability vs Consistency, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = availability_vs_consistency(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: Availability vs Consistency
Change the variables below and predict what breaks first in Availability vs Consistency. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Availability vs Consistency, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Availability vs Consistency. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Availability vs Consistency?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Availability vs Consistency, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Availability vs Consistency, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for Availability vs Consistency: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using Availability vs Consistency. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Consistency prevents bugs where users see wrong data (critical for finance, inventory, safety).
- +Availability keeps the system usable during partitions (critical for social, content, real-time).
- +Naming the trade-off explicitly prevents 'why is this slow/stale?' confusion later.
- −Strong consistency requires coordination (quorum, consensus) — adds latency and reduces availability during partitions.
- −Eventual consistency requires handling stale reads in application code (conflict resolution, idempotency).
- −Mixed systems (consistent writes, eventually consistent reads) add complexity.
How this breaks in production
- Choosing availability for financial data — leads to lost money and disputes.
- Choosing consistency for social feeds — makes the system feel slow and unavailable.
- Forgetting that 'eventual consistency' means 'eventually converged', not 'eventually correct' — conflicts can still occur.
Don't fall into these traps
- •Treating 'consistency' as binary — it's a spectrum (linearizable, sequential, causal, eventual).
- •Assuming 'eventually consistent' means 'always eventually correct' — it means eventually converged, which can still be wrong.
- •Forgetting that strong consistency has a latency cost, not just an availability cost.
Real systems using this
How real systems implement this
- DynamoDB — Configurable consistency: eventually consistent reads (default) for availability, or strongly consistent reads (optional) for correctness. The user chooses per request.
- Google Spanner — Strongly consistent (CP) using Paxos consensus across regions. Trades higher latency for consistency — used for financial systems like AdWords billing.
Practice saying it out loud
- Q1What's the difference between availability and consistency? When would you choose each?
- Q2Give an example of a system that should prioritize consistency, and one that should prioritize availability.
- Q3Can you have both? What's the cost?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
CAP Theorem