ACID vs BASE

1The core idea#

ACID and BASE are two philosophies about what a database promises when many things happen at once and machines occasionally die.

ACID: Atomicity, Consistency, Isolation, Durability.

• The promise: a transaction either fully happens or does not happen at all.
• Once confirmed, it is as if no other transaction ran at the same time.
• Picture transferring 500 rupees between two bank accounts: debit one, credit the other.
• If the power dies between those steps, ACID guarantees you never end up with money gone from one account but never arrived in the other.

BASE: Basically Available, Soft state, Eventually consistent.

• An almost-joke name built to contrast with ACID (the chemistry pun: acids vs bases).
• The promise is weaker on purpose: the system stays up and answers even during trouble.
• Replicas might disagree for a short window, and if you stop writing, all copies converge eventually.
• Picture a like counter: 1,042 on one server and 1,045 on another for two seconds hurts nobody.

The part people miss: these are not database brands.

• Postgres gives you eventual-consistency behavior the moment you read from async replicas.
• DynamoDB, usually filed under BASE, offers strongly consistent reads if you ask (and pay double the read-capacity cost per read).
• The labels describe guarantees, not products. Know the configured guarantee, not the logo.

2How it works#

A quick tour of what makes ACID expensive and what BASE trades away.

An ACID write on a single node uses a write-ahead log and locks.

• Before changing the real data pages, the database writes the intended change to a log on durable storage and flushes it to disk.
• That fsync is the slow part, often the single biggest cost.
• Locks or multi-version snapshots keep concurrent transactions from seeing each other's half-finished work.
• On commit the log entry is the source of truth, so crash recovery can replay it.

Now spread that across machines.

• To keep ACID guarantees across replicas, the replicas must agree on order before you confirm the write.
• That agreement is a consensus round (Raft, Paxos) or a two-phase commit.
• Either way the write waits for a quorum of nodes to acknowledge.
• More nodes and more network distance means more latency per write.

BASE systems cut that cord.

• You write to one node, it says "got it," and replication to the others happens in the background.
• The write is fast because it did not wait for anyone.
• The cost: for a short window, a reader hitting a different replica sees stale data.

Here is a BASE write path next to an ACID distributed commit.

The flow over time for an eventually consistent read looks like this.

3A worked example with real numbers#

Numbers make the trade concrete. Say I run a service across three data centers: Mumbai, Singapore, and Frankfurt.

• Round-trip network latency between any two of them is roughly 120 ms.
• A local disk fsync on commit costs about 2 ms.
• A single-node, same-rack write with no cross-region hop is sub-millisecond.

BASE write (ack from the nearest node).

• The client talks to the Mumbai replica, which flushes its log locally and acks.
• Cost is roughly the local fsync plus a little overhead, call it about 3 ms.
• Replication to Singapore and Frankfurt happens in the background and converges within maybe 150 ms.
• The user already got their 200 OK at the 3 ms mark.

ACID write with a majority quorum across the three regions.

• The coordinator in Mumbai has to get a second region to agree before it commits.
• So the write pays one cross-region round trip to the nearest other region.
• That is about 120 ms of network plus the 2 ms fsync, so roughly 122 ms per write.
• Put the coordinator in Frankfurt with Singapore as the quorum partner and you pay the same order of cost.

The hidden cost is connection pressure, not just the per-write number.

• Suppose this service handles 10,000 writes per second.
• On BASE each client thread is blocked 3 ms, so about 30 concurrent write threads sustain the rate.
• On cross-region ACID each thread is blocked 40x longer, so you need roughly 1,220 concurrent threads (or connection slots, or in-flight requests) for the same 10,000 writes per second.
• That connection pressure is what kills naive "just make it consistent everywhere" designs.

The honest conclusion: choose per field.

• Data that must be correct (account balances, seat inventory) goes on the 122 ms path, because being wrong there is a refund or a lawsuit.
• Data that can drift (view counts, feed items) goes on the 3 ms path.
• You are not choosing one number for the whole system. You are choosing per field.

4Trade-offs#

This is where interviews are won. The honest framing: you trade write latency and availability against read consistency and transactional safety.

CAP is the reason this trade exists.

• During a network partition a distributed system can be consistent or available, not both.
• ACID-style systems usually pick consistency: they would rather reject a write than let two nodes disagree.
• BASE systems pick availability: keep taking writes, sort out disagreements later.
• Even on a healthy network with no partition you pay a latency tax for consistency (the 122 ms versus 3 ms above). That is the PACELC extension of CAP, a great thing to name if you can explain it.

"Eventually" is not a vague word. It has a number.

• On a well-run system eventual usually means tens to a few hundred milliseconds (the example converged in about 150 ms).
• Under load or cross-region replication I have seen convergence windows stretch to seconds.
• If a code path cannot tolerate a 2-second-stale read, you cannot put that data on pure BASE without extra guards.

The developer cost is real and underrated.

• ACID lets a junior engineer write BEGIN; UPDATE; UPDATE; COMMIT; and be correct.
• BASE pushes that burden into application code.
• Someone has to decide what happens when two users edit the same document and both writes land.
• That is design work, testing work, and on-call work.

5Where it is used#

Reach for ACID when being wrong is expensive and visible.

• Payments and ledgers. A double-spend or lost debit is a lawsuit, not a bug ticket. The textbook case for a reason.
• Inventory with hard limits. Selling the last concert ticket twice means refunds, angry customers, and a manual mess.
• Anything with invariants across rows. "Total credits must equal total debits." "A user cannot be in two rooms at once." Multi-row invariants want transactions.

Reach for BASE when uptime and scale beat momentary accuracy.

• Social feeds and timelines. A friend's new post showing up 400 ms late on one device is nobody's bug.
• View counts, likes, reactions. These are estimates in users' minds already. Converge them in the background.
• Shopping carts and sessions. Amazon's Dynamo paper used eventual consistency for carts specifically because never losing a cart addition (staying available) mattered more than perfect instant consistency. Worst case, a removed item reappears and the user removes it again.
• Product catalogs, user profiles, DNS. Read-heavy, rarely conflicting, fine slightly stale.

6Common pitfalls and gotchas#

Treating the database label as the guarantee.

• "We use MongoDB so we are eventually consistent." MongoDB has had tunable write concerns and multi-document transactions for years.
• Postgres read replicas are eventually consistent.
• Know the actual configured guarantee, not the logo.

Forgetting that eventual consistency needs a conflict strategy.

• If two replicas both took a write to the same key, what wins?
• Last-write-wins is simple and silently drops data when clocks skew.
• CRDTs merge cleanly but only for certain data shapes (counters, sets).
• "Eventually consistent" with no stated resolution rule is an unfinished design.

Read-your-own-writes surprises.

• A user updates their profile photo, the write goes to the primary, then their next read hits a lagging replica and shows the old photo.
• They think it failed and upload again.
• Fix with read-your-writes consistency: pin that user's reads to the primary for a few seconds, or route by session.
• Interviewers love this scenario because it is subtle and common.

Assuming ACID means slow and BASE means fast, always.

• A single-node Postgres doing simple transactions is blisteringly quick, often sub-millisecond and faster than a distributed BASE store with network hops.
• The cost of ACID shows up when you distribute it (the jump from sub-millisecond to 122 ms in the worked example).
• Do not reach for eventual consistency to solve a performance problem you do not have yet.

7How it shows up in interviews#

Interviewers use this topic to check whether you reason about data per use case or just pattern-match buzzwords.

What they probe.

• Can you justify the choice for a specific field, not the whole system? "User balances are ACID, the activity feed is BASE" beats "we use a relational database."
• Do you know what "eventually" costs the user and the developer? Can you put a number on it?
• Can you connect it to CAP and explain the partition behavior?
• Do you handle the messy parts: conflicts, stale reads, read-your-writes?

The gap between those two answers is the whole interview. One is a logo. The other is an engineer who has felt the 40x latency difference and knows which data earns it.

Bonus points.

• Mention read-your-writes for profile edits.
• Name the Saga pattern instead of blindly reaching for 2PC.
• Say PACELC if you can actually explain it: consistency costs latency even when the network is fine.
• Those three signal that you have operated these systems, not just read about them.

Nobody gets promoted for choosing ACID or BASE. They get promoted for drawing a clean line through their data.

Next, try the System Design Question walkthrough on designing a ticket-booking system, where this exact ACID-for-inventory, BASE-for-browse split decides whether your design survives a flash sale.