"Strong consistency" and "eventual consistency" are the two ends of a spectrum that drives every data-layer decision. Pick strong when you must (payments, inventory, anything involving money or exclusivity). Pick eventual when you can (feeds, analytics, notifications) — you get far better scale and availability in exchange.
ACID is the vocabulary for strong consistency. BASE is the vocabulary for eventual. Both are sloppy acronyms, but both capture a real tradeoff.
A — Atomicity. A transaction is all-or-nothing. If one statement in the transaction fails, all changes are rolled back. You never see "the debit happened but the credit didn't."
C — Consistency. (The overloaded word.) Every transaction moves the database from one valid state to another valid state. Foreign keys hold, check constraints hold, unique indexes hold. This is not the same as the "C" in CAP.
I — Isolation. Concurrent transactions don't see each other's partial work. Defined by isolation levels (see variants below). Most databases default to Read Committed; Serializable is the strongest and slowest.
D — Durability. Once committed, a transaction survives crashes, power loss, everything short of disk destruction. Usually via write-ahead log (WAL) synced to disk before commit returns.
BA — Basically Available. The system always responds to reads and writes. Prefers returning stale or partial data over failing the request.
S — Soft state. The state of the system may change over time even without new inputs — replicas converge asynchronously. Looking at one replica vs another can return different values for a brief window.
E — Eventual consistency. If no new writes happen, all replicas will eventually converge to the same value. "Eventually" is typically milliseconds to seconds, rarely longer.
BASE is what DynamoDB, Cassandra, and Mongo (in default mode) give you. It's the price of being always available during network partitions — see CAP.
| Level | What it prevents | What it allows | Default in |
|---|---|---|---|
| Read Uncommitted | Nothing | Dirty reads (see uncommitted changes) | Rarely used |
| Read Committed | Dirty reads | Non-repeatable reads (same query returns different rows in one txn) | Postgres, Oracle, SQL Server |
| Repeatable Read | Non-repeatable reads | Phantom reads (new rows appear in range scan) | MySQL InnoDB |
| Serializable | Everything — as if transactions ran one at a time | Nothing unsafe | Rarely default (costly) |
Pick Serializable for financial logic. Pick Read Committed (default) for almost everything else. Tune up only when you hit a specific anomaly.
You write code against invariants ("balance never goes negative"; "order has exactly N items"). The DB enforces them. Bug surface shrinks enormously. Price: strong coordination — every write talks to every replica (or a consensus group), limiting write throughput and regional distribution.
Writes commit locally and propagate async → huge throughput, cross-region writes. Price: your app code handles edge cases — "what if the counter increments from 99 → 100 → 99 when replicas converge late?" You write conflict-resolution logic (last-write-wins, CRDTs, vector clocks).
Read Committed is the default but has subtle bugs. The classic: two doctors on-call. The rule: "at least one doctor must be on-call." Both try to remove themselves from on-call concurrently.
This is write skew. Each transaction individually saw a valid state; their interleaving produced an invalid one. Read Committed doesn't prevent it. Serializable does (at ~30–50% throughput cost) — or add a SELECT ... FOR UPDATE to materialize the intent.
Moral: default isolation is fine for 99% of code; the 1% (exclusivity rules, financial invariants) needs explicit locks or Serializable.
E-commerce uses ACID for order placement (inventory invariant). Payment gateway uses Serializable for double-charge protection. News feed uses BASE for engagement counters (like/share counts). Ticketmaster uses ACID with explicit row locks to prevent double-booking a seat.
