"ACID vs BASE"
The two philosophies of data consistency compared: ACID transactions (atomicity, consistency, isolation, durability) versus BASE (basically available, soft state, eventual consistency), what each guarantees, the databases that follow them, and how real systems combine both.
Reading is half of it. See this used in a real interview: walk through Design a Payment System →
"Should this use an ACID database or is BASE fine?" is a classic way to ask about consistency trade-offs. ACID describes the guarantees of traditional database transactions; BASE describes the looser model many distributed NoSQL systems adopted to stay available and scale. The labels are simplifications, and modern databases blur the line, but the trade-off they name is real and appears in every design.
ACID
A transaction is a group of operations treated as one unit:
- Atomicity: all of it happens or none of it does. A transfer debits and credits, or neither.
- Consistency: the transaction moves the database from one valid state to another, respecting constraints (unique keys, foreign keys, checks). Mostly the application's job, enforced with the database's help.
- Isolation: concurrent transactions do not see each other's partial work; the strength depends on the isolation level. See transactions and isolation.
- Durability: once committed, the change survives crashes (written to a log and synced). See storage engines.
Classic examples: PostgreSQL, MySQL with InnoDB, Oracle, SQL Server; also distributed SQL databases across many machines. See Spanner and distributed SQL.
BASE
A description of systems that prioritise availability and partition tolerance:
- Basically available: the system keeps responding, even during failures, possibly with stale or partial data.
- Soft state: replicas may hold different values at a given moment, changing as replication catches up.
- Eventual consistency: if writes stop, all replicas converge to the same value.
Classic examples: Cassandra, early DynamoDB, Riak, DNS, many caches. See quorums and leaderless replication and CAP theorem.
Comparison
| ACID | BASE | |
|---|---|---|
| Priority | correctness | availability and scale |
| Multi-record updates | atomic transactions | usually single-record atomicity only |
| Reads after writes | consistent (on the primary) | may be stale |
| Behaviour during partitions | may refuse some requests | keeps serving, reconciles later |
| Conflict handling | prevented by locking or validation | resolved after the fact (last-writer-wins, merges) |
| Write latency across regions | higher (coordination) | low (local writes) |
| Application complexity | lower for correctness | higher: handle staleness and conflicts |
The blur
The labels are less clean today:
- Many NoSQL databases offer transactions (DynamoDB transactions, MongoDB multi-document transactions, Cassandra lightweight transactions) and tunable consistency per request.
- Relational databases replicate asynchronously to read replicas, which are eventually consistent.
- Distributed SQL gives ACID across regions at a latency cost.
So the useful question is not "ACID or BASE database?" but "which operations need which guarantees?"
Which operations need ACID
- Money: balances, ledgers, payments, refunds. See payments and ledgers.
- Inventory and reservations: seats, rooms, stock. See Design Ticketmaster.
- Uniqueness: usernames, idempotency keys, one booking per slot.
- Multi-step state changes that must not be half-applied within one service.
Which can be BASE
- Social data: likes, follower counts, feeds, view counts. See Design a News Feed.
- Caches and derived data: search indexes, recommendations, analytics.
- High-volume append data: messages, events, metrics, location updates, where each write is independent. See Design WhatsApp.
Combining them
Most real systems use both:
- An ACID store for the core transactional entities (orders, payments, accounts).
- BASE stores for high-volume or derived data, fed from the ACID store through events or change data capture. See change data capture.
- Across services, there is no global ACID transaction; sagas with compensation and idempotency give eventual consistency with business-level correctness. See distributed transactions and idempotency.
In the interview
Avoid "we use NoSQL so it is eventually consistent" as a blanket statement. Say instead: "Payments and the ledger are in Postgres with serializable transactions; the activity feed and counters are eventually consistent in Cassandra and Redis, fed by events from the order service." See Design a Payment System.
Checklist
- Know what each ACID letter guarantees, and that isolation has levels.
- Know BASE as availability first, convergence later.
- Choose per operation, not per system.
- ACID for money, inventory, uniqueness and multi-step local changes.
- BASE for social, derived, cached and high-volume append data.
- Bridge them with CDC, events, sagas and idempotency.