Engineering Atlas by Abhishek Goyal
System design / Databases

ACID vs BASE: Two Promises a Database Can Make (Video + Notes)

A short video and a five-minute read on ACID vs BASE: what each letter really promises, why distributed stores trade strict guarantees for availability, which systems sit where, and how to pick per piece of data in a system design interview.

By Abhishek Goyal Read time ~5 min read Level Beginner → Intermediate Stack PostgreSQL, MySQL, Cassandra, DynamoDB, MongoDB
On this page
  1. ACID: the bank's promise
  2. BASE: the social feed's promise
  3. Side by side
  4. How this connects to CAP
  5. How to say it in the interview

You transfer ₹500 to a friend. Your balance drops, theirs goes up, and at no moment does the money exist in both accounts or in neither. Now you like a post, and your friend sees 1,203 likes while you see 1,204. Nobody minds. Those two experiences come from two different promises a database can make: ACID and BASE. The video walks through both; the notes below are the version you can skim before an interview.

Where this fits: Part of the Databases under the hood series. This is the quick, big-picture comparison. Transaction isolation levels goes deep on the "I" in ACID.

01ACID: the bank's promise

ACID Definition

A set of guarantees for a transaction, a group of reads and writes the database treats as one unit. Relational databases like PostgreSQL and MySQL (InnoDB) are built around it.

  • Atomicity: all of the transaction happens, or none of it does. The debit and the credit land together.
  • Consistency: every commit moves the data from one valid state to another, as far as your constraints, keys and checks define "valid".
  • Isolation: transactions running at the same time don't trample each other, to the degree the isolation level promises.
  • Durability: once COMMIT returns, the data survives a crash, because it is in the write-ahead log on disk.

The price is coordination. To keep those promises, the database takes locks, checks versions and waits for the log to reach disk. On one machine that is cheap. Spread across many machines and regions, every write needs agreement, and agreement costs latency and, during a network split, availability.

02BASE: the social feed's promise

BASE Definition

Basically Available, Soft state, Eventually consistent. A design style for distributed data that keeps answering requests even when replicas disagree, and lets them converge later. Dan Pritchett popularised the term in a 2008 ACM Queue article about eBay's architecture.

  • Basically available: the system keeps serving reads and writes when some nodes are down or unreachable, even if an answer is slightly stale.
  • Soft state: the data on a replica can change without a new write, as updates from other replicas arrive in the background.
  • Eventually consistent: if writes stop, every replica ends up with the same value. "Eventually" is usually milliseconds, but nothing guarantees a bound.

Think of a like counter on a post. Two data centres each accept likes locally and sync with each other. A reader might see 1,203 in Mumbai and 1,204 in Singapore for a moment. That is a fine trade for a counter, and a terrible one for a bank balance.

03Side by side

ACIDBASE
Main promiseCorrect, isolated, durable transactionsAlways answer, converge later
After a write, readers seeThe new value (on the primary)Possibly the old value for a short while
During a network splitMay refuse or delay writes to stay correctKeeps accepting writes, reconciles afterwards
Scaling writesHarder: coordination between nodesEasier: nodes accept writes independently
Typical systemsPostgreSQL, MySQL, Spanner, CockroachDBCassandra, DynamoDB default reads, DNS, CDN caches
Good fitPayments, orders, inventory, bookingsLikes, views, feeds, presence, analytics events

Many candidates get this wrong

"SQL is ACID, NoSQL is BASE" was roughly true in 2010. It isn't today. MongoDB has multi-document ACID transactions since 4.0, DynamoDB has transactions and strongly consistent reads, and Cassandra lets you choose a consistency level per query. Distributed SQL databases like Spanner and CockroachDB keep ACID across regions. Treat ACID and BASE as ends of a dial you set per operation, not as labels on a database brand.

04How this connects to CAP

The CAP theorem says that during a network partition, a distributed store must pick between consistency (every read sees the latest write) and availability (every request gets an answer). ACID-style systems lean towards consistency; BASE systems lean towards availability. Note the trap: the "C" in ACID (valid data under your rules) and the "C" in CAP (every replica agrees) are different ideas that happen to share a letter. The consistency models section of the Databases guide goes further, from linearizable reads to eventual consistency.

05How to say it in the interview

When I ask "SQL or NoSQL?", I'm not looking for a brand name. I'm listening for whether you split the data by how wrong it is allowed to be.

Interview talk track

"I'll pick consistency per piece of data, not per system. Orders, payments and seat inventory need ACID: a transaction that debits stock and creates the order together, so I'll keep them in Postgres. Likes, view counts and the feed can be eventually consistent: a count that's a second behind is fine, and I'd rather stay available, so those go to a BASE-style store or a cache that syncs asynchronously. If the interviewer pushes on scale for the ACID side, I'll shard by user or order ID before giving up transactions."

Whiteboard summary

  • ACID: atomic, valid, isolated, durable. Cost: coordination.
  • BASE: available, soft state, eventually consistent. Cost: stale reads, conflict handling.
  • Money, stock, bookings → ACID. Counters, feeds, presence → BASE.
  • It's a per-operation dial, not "SQL vs NoSQL".

Go deeper

Transaction isolation levels: every anomaly the "I" in ACID can let through, and how to stop double booking.

Related

Further reading

Keep learning