Two systems both store a number. One is a wallet balance. The other is a follower count. If the wallet is wrong for 200 milliseconds, someone can spend money twice. If the follower count is wrong for 200 milliseconds, nobody notices and nobody cares.
That difference is the whole subject. ACID and BASE are two answers to one question: when a database cannot be both perfectly correct and always available, which one does it give up? Getting the answer wrong is expensive in one direction and embarrassing in the other, which is why it comes up in almost every system design interview you will sit.
This guide covers what each model guarantees, what "eventual" means once real traffic hits it, how the CAP theorem connects the two, and how to pick between them using the systems you already work on.
What ACID Actually Guarantees
ACID is 4 promises a database makes about a transaction. We have a deeper guide to ACID compliance if you want the full treatment, but here is what each letter buys you.
Atomicity means the transaction is all or nothing. Debiting one account and crediting another are one unit. If the second step fails, the first is undone. You never end up with money that left one place and arrived nowhere.
Consistency means the database refuses to move from one valid state to another invalid one. Your foreign keys, unique constraints, and check constraints hold before the transaction and after it. Note that this is not the same "consistency" as the C in CAP, which is a common source of confusion and a good thing to be precise about in an interview.
Isolation means concurrent transactions do not see each other's half-finished work. Two people buying the last seat at the same moment cannot both succeed. This is the promise with the most nuance, because databases offer it in levels, and the default level in PostgreSQL and MySQL is not the strictest one.
Durability means once the database says "committed", the write survives a power cut. The record is on disk, or in a replicated log, before the acknowledgement goes back to your application.
The cost of these 4 promises is coordination. To guarantee them across more than one machine, the machines have to agree before anyone is told the write succeeded. Agreement takes network round trips, and network round trips are the thing that stops a system scaling horizontally without limit.
What BASE Trades Away, and What It Buys
BASE stands for Basically Available, Soft state, Eventually consistent. The name is a chemistry joke about being the opposite of acid, and it describes a system that would rather answer with slightly old data than not answer at all.
Basically available means the system responds to every request, even when some nodes are unreachable. The response may be stale, and it may be a partial result, but it is a response.
Soft state means the data can change without an incoming write, because replication and reconciliation are still working in the background.
Eventually consistent means that if writes stopped, every replica would converge on the same answer. The word doing the work there is "if". Writes never stop in production, so what you are actually promising is that the gap between replicas stays small enough that users tolerate it.
In exchange you get horizontal scale and availability that ACID systems cannot match. A write can be accepted by whichever node is nearest and healthy, without waiting for a quorum in another region to agree. For a feed, a cache, a session store, a product catalogue, or an analytics pipeline, that is a straight win.
Where CAP Fits In
The CAP theorem is stated more loosely than it should be. The precise version is narrow: when a network partition splits your nodes, you must choose between consistency and availability. You do not get to choose partition tolerance, because networks fail whether you consent or not.
Two things follow, and both are worth saying out loud in an interview.
First, CAP only describes behaviour during a partition. On a normal day, a well-built distributed database is both consistent and available. CAP is a statement about failure, not about steady state.
Second, the choice is not binary in practice. Most modern databases let you pick per operation. You can read a user's own profile with a strong read and read the public timeline with a stale one, in the same request, in the same database. Treating consistency as a per-query decision rather than a per-database one is what separates an engineer who has read about CAP from one who has shipped with it.
ACID vs BASE at a Glance
| Dimension | ACID | BASE |
|---|---|---|
| Read after write | Always sees the newest value | May see an older value briefly |
| Behaviour during a partition | Rejects writes it cannot confirm | Accepts writes and reconciles later |
| Scaling shape | Vertical first, sharding is manual work | Horizontal by design |
| Write latency | Higher, coordination is required | Lower, local acknowledgement |
| Conflict handling | Prevented by the database | Your problem, resolved after the fact |
| Typical stores | PostgreSQL, MySQL, Oracle, CockroachDB | Cassandra, DynamoDB, Riak, most caches |
| Fits | Money, inventory, identity, bookings | Feeds, search, sessions, metrics, catalogues |
Two Worked Examples
A Payments Ledger Needs ACID
Take a wallet service of the kind Paystack, Flutterwave, or M-Pesa sit behind. A transfer debits one balance and credits another. The requirements are not negotiable: the 2 updates happen together or not at all, no 2 concurrent transfers can drive a balance below zero, and once the sender sees "sent", a crash cannot undo it.
Every one of those is an ACID guarantee, and none of them can be bolted on afterwards. If you accept a transfer on a replica that has not yet heard about the previous transfer, you have authorised a double spend, and you will find out from a reconciliation report rather than from your monitoring.
This is also why the ledger is usually the smallest, most boring, most relational part of a fintech system. Keeping it small keeps the coordination cost affordable.
A Social Feed Needs BASE
Now take the feed on the same product, or a notifications list, or a "people you may know" panel. A user posts. Should every follower's feed update before the post request returns?
Answering yes means a single write waits on a fan-out to thousands of rows across several regions, and the whole feature goes down when one region is unreachable. Answering no means the post appears in most feeds within a second, in all of them within a few seconds, and the service stays up through a partition. Nobody can tell the difference by looking, and the second design costs a fraction of the first to run.
The same product, 2 features, 2 correct answers. Systems do not pick a consistency model. Data does.
How to Choose, in Four Questions
When you are designing a table or a service and cannot decide, work through these in order.
1. What is the cost of a reader seeing a value that is 2 seconds old? If the answer is "nothing", you have permission to use BASE. If the answer involves money, safety, access control, or a legal obligation, you need ACID.
2. Can 2 writes conflict, and can you resolve the conflict automatically? A view counter resolves by addition. Two people editing the same document do not resolve by any rule you can write down. Unresolvable conflicts push you towards ACID.
3. What must be true during a partition? Decide in advance whether the feature should refuse to work or work with stale data. Writing that decision into your design document is the difference between a deliberate trade and an outage nobody understands.
4. How much data is this, honestly? Teams reach for BASE because of scale they do not have. A single well-indexed PostgreSQL instance handles far more traffic than most products ever see, and it gives you ACID for free. Choosing eventual consistency you do not need means paying for conflict resolution you could have avoided. If your bottleneck is a missing index rather than a missing shard, start with indexing.
What Interviewers Are Listening For
"ACID vs BASE" is rarely the real question. The real question is whether you can classify data by its tolerance for staleness, and defend the classification.
Weak answers describe the acronyms. Strong answers do 3 things. They split the system's data into categories and assign a model to each with a reason. They name a specific failure the choice prevents, such as a double spend or a lost update, rather than saying "data integrity". And they state the cost of their own choice out loud, because an engineer who cannot name the downside of their design has not finished thinking about it.
A good practice drill is to take a system you use daily and sort every piece of its data into 2 columns. If you want more structured preparation, our backend interview questions cover this territory, and you can rehearse explaining it out loud with the AI mock interviews. The gap between knowing this and being able to say it under pressure is wider than most people expect.
Common Mistakes
The 4 we see most often, in roughly that order.
Treating the whole application as one choice. Almost every system needs both. Deciding once, globally, is how teams end up running a distributed store for a ledger or a single relational instance for an event firehose.
Confusing the C in ACID with the C in CAP. The first means your constraints hold. The second means all readers see the same value. They are unrelated, and mixing them up is one of the fastest ways to sound underprepared.
Assuming the default isolation level is the strict one. PostgreSQL and MySQL both default to a level that permits anomalies the strictest level forbids. If you have never checked which level your service runs at, check this week.
Calling a cache "eventual consistency". An eventually consistent store converges on its own. A cache with no invalidation strategy converges when the time to live expires, which is not the same promise and fails differently. If you are adding a cache layer, our guide to caching with Redis covers the invalidation part properly.
Summary
ACID and BASE are not competing technologies and neither one is more advanced. They are 2 answers to a question every distributed system eventually asks: when correctness and availability cannot both be had, which do we protect?
ACID protects correctness through coordination, and charges you in latency and scaling effort. BASE protects availability through independence, and charges you in stale reads and conflict resolution. Money, inventory, identity, and bookings take the first. Feeds, sessions, search, caches, and metrics take the second. Most real systems run both, deliberately, in the same codebase.
The skill worth building is not memorising the acronyms. It is looking at a piece of data and knowing, quickly and for a stated reason, how stale it is allowed to be. Practise that on the systems you already use, and the interview version takes care of itself. If you want to build the muscle on real systems rather than on paper, the backend projects catalogue has services where this decision has actual consequences.
Frequently Asked Questions
What Is the Difference Between ACID and BASE?
ACID is a set of guarantees a single database makes about a transaction: it either fully happens or does not happen at all, it never leaves the data in a broken state, concurrent transactions do not corrupt each other, and once it is committed it survives a crash. BASE is the opposite trade. It gives up the promise that every reader sees the newest write immediately, and gets availability and horizontal scale in return. ACID protects correctness. BASE protects uptime.
Is BASE the Same as NoSQL?
No. BASE describes a consistency model and NoSQL describes a family of data stores. Many NoSQL databases default to BASE behaviour, but several now offer ACID transactions, and you can build a BASE-style system on top of PostgreSQL by sharding it and accepting stale reads across shards. Judge the configuration you are running, not the label on the product page.
What Does Eventual Consistency Actually Mean?
It means that if writes stop, every replica will agree after some delay. It says nothing about how long that delay is. On a healthy cluster it is usually milliseconds. During a network partition or a replica restart it can be seconds or longer. The engineering question is never whether the delay exists, it is what your users see while it lasts.
Can One System Use Both ACID and BASE?
Yes, and most production systems do. A payments service will keep balances and ledger entries in an ACID database while the activity feed, search index, and recommendation cache built from those same events run on BASE storage. The rule of thumb is that money and identity get ACID, while views and derived data get BASE.
How Does the CAP Theorem Relate to ACID and BASE?
CAP says that when the network between your nodes breaks, you must choose between staying consistent and staying available. ACID systems choose consistency and refuse writes they cannot safely accept. BASE systems choose availability and accept writes they will reconcile later. CAP only applies during a partition, so it describes how a system behaves in failure, not how it behaves every day.
Which Should a Junior Backend Engineer Learn First?
Learn ACID first, in a relational database. Transactions, isolation levels, and what a rollback protects you from are the foundation every interviewer probes, and they are the concepts that make BASE make sense later. Once you can explain why a lost update happens under read committed, eventual consistency stops being mysterious.
