BASE
The consistency model most NoSQL and distributed systems choose instead of ACID — and why that's a deliberate trade, not a lesser one.
Overview
BASE — Basically Available, Soft State, Eventual Consistency — is the consistency model most NoSQL and distributed systems adopt instead of ACID, trading strict, immediate guarantees for the ability to scale horizontally and stay available during network problems.
Why It Exists
ACID's strict guarantees get genuinely expensive to provide across many machines spread over a network — every transaction would need to coordinate with every replica before it could safely commit, which either kills availability (a write blocks if any replica is unreachable) or kills latency (every write pays a coordination round trip). Many real applications — like counts, product view counts, activity feeds — can tolerate a brief window of staleness far better than they can tolerate an outage, and BASE exists specifically for that trade. CAP theorem, covered next, is the formal reason this trade-off is unavoidable at scale.
Real World Example
A 'like' count on a post updates on the server that received the like immediately. A follower reading that same post from a different replica a moment later might see the old count for a few hundred milliseconds, until replication catches up. A BASE system accepts that brief inconsistency in exchange for never blocking either the write or the read while replicas sync.
Example Data
Same post, two replicas, briefly out of sync — this is Eventual Consistency in practice
| Replica | Time | like_count |
|---|---|---|
| Node A (received the write) | t = 0ms | 101 |
| Node B (a different replica) | t = 0ms | 100 (stale) |
| Node B (after replication) | t = 250ms | 101 |
The Three Words, One at a Time
Basically Available
The system guarantees a response to every request, even during a partial failure. That response might come from a stale replica, but the system always answers rather than blocking or erroring out.
Soft State
The system's state can change over time even without new input — purely from eventual replication and convergence happening in the background. This is a direct contrast to ACID, where state only ever changes via an explicit, committed transaction.
Eventual Consistency
Given enough time with no new writes, every replica converges on the same value — but there's no guaranteed bound on exactly when that convergence happens.
Diagram
A write is acknowledged immediately; consistency catches up in the background
Write hits Node A
Node A acknowledges immediately
no waiting on other replicas
Replication propagates in the background
Node B eventually converges
a read from Node B in between might see stale data
Common Mistakes
Assuming 'eventually consistent' means 'consistent within milliseconds'
Why: There's no universal time bound — under load or during a partition, 'eventual' can stretch to seconds or longer, and application logic that assumes near-instant convergence can visibly show wrong data to users.
Fix: Design the UI and logic to tolerate visible staleness, or use a read-your-writes/session-consistency guarantee where the specific engine offers one.
Applying BASE thinking to data that genuinely needs strict correctness
Why: BASE trades correctness for availability — the wrong trade for data like financial balances or inventory counts that must never go negative, where a wrong answer is a real problem, not just an inconvenience.
Fix: Keep genuinely strict-correctness data on an ACID-guaranteeing store, and reserve BASE for data that can tolerate staleness.
Treating BASE as 'no guarantees at all'
Why: BASE is a deliberately named, real model with specific properties — the system always responds, and it always eventually converges. It's not just 'consistency turned off,' and systems built on it still need to carefully reason about which anomalies are acceptable.
Fix: Understand BASE's actual guarantees before dismissing it as unstructured — it's a specific trade-off, not an absence of one.
Interview Questions
What does BASE stand for, and how is it philosophically different from ACID?
Basically Available, Soft State, Eventual Consistency. Where ACID prioritizes strict, immediate correctness even if that means blocking, BASE prioritizes always responding and scaling horizontally, accepting that data might be briefly stale across replicas.
Give one example where eventual consistency is an acceptable trade-off, and one where it isn't.
Acceptable: a social media like count or view counter, where a brief lag in an exact number doesn't meaningfully affect anyone. Not acceptable: an account balance or inventory count, where showing a stale, too-high number could let someone overdraw funds or oversell stock that isn't actually available.
How would you design a 'like count' feature so it shows a wrong number only rarely and self-corrects?
Accept the write locally and acknowledge it immediately (Basically Available), replicate asynchronously to other nodes, and periodically reconcile counts against an authoritative source (e.g. a background job that recomputes the true count from an event log) so any divergence self-heals over time (Eventual Consistency) instead of requiring every read to coordinate with every replica first.
Production Best Practices
Do
✓Use BASE for data that can tolerate brief staleness in exchange for availability and scale.
✓Design UI and application logic to tolerate visible staleness where BASE is used.
✓Reconcile/self-heal divergent replicas with a background process rather than assuming they'll never drift.
Don't
✗Don't use BASE-style eventual consistency for data where a wrong answer causes real harm (balances, inventory).
✗Don't assume 'eventual' has any specific time bound.
✗Don't treat BASE as an excuse to skip reasoning about which anomalies your application can actually tolerate.
Comparison
| ACID | BASE | |
|---|---|---|
| Guarantee style | Strict, immediate | Eventual, best-effort |
| Availability during a partition | May block or refuse | Keeps responding |
| Typical use case | Payments, inventory | Social counts, activity feeds |
| Example systems | PostgreSQL, traditional RDBMS | Cassandra, DynamoDB |