ACID vs BASE Properties in Databases

For example, a store has three copies of a stock count. A sale changes the count from 10 to 9 on copy A. For about 300 ms, copies B and C still show 10. A reader who reaches copy B during that time sees the old value. Then the update arrives, and all three copies show 9.

One Word, Two Meanings

The word "consistency" causes a common mistake. The C in ACID and the C in the CAP theorem are not the same thing.

• The C in ACID is about one database following its rules. Every transaction leaves the data valid: no negative balances, and no order without a customer. A single machine can make this promise by itself.
• The C in CAP is about copies agreeing. Every read returns the newest write, no matter which copy answers. This promise only matters when the data is stored on more than one machine.

When people say a BASE database "gives up consistency", they mean the CAP kind. Copies may briefly disagree with each other. They do not mean the database breaks its data rules.

What Happens During a Network Failure

The CAP theorem explains why both styles exist. It names three properties: Consistency, Availability, and Partition tolerance.

A partition is a network failure that cuts some machines off from others. Partitions happen whether you plan for them or not. So a distributed system must handle them, and each system must choose how to behave during one. While the machines cannot reach each other, a system does one of two things:

• A system that favors consistency refuses. The user sees an error or a delay, but never an outdated value.
• A system that favors availability answers. The user always gets a response, but it may be outdated.

Traditional ACID databases usually favor consistency, and BASE databases usually favor availability. The CAP Theorem lesson explains this in depth.

ACID vs. BASE

The row people often miss is "who resolves disagreements". In a BASE database, copies can disagree, and something must decide which value wins. That job moves into your application. Common approaches are:

• Last write wins: keep the value with the newest timestamp, and discard the others.
• Version vectors: track which updates each copy has seen, to detect conflicts.
• Merge rules: combine conflicting values in a way that fits the data. For example, merge two versions of a shopping cart by keeping the items from both.

Choosing Between Them

• Money, stock that must not be oversold, or bookings: use ACID transactions. A wrong value is worse than a slow or failed request.
• Likes, view counts, feeds, and similar data: BASE is usually fine. A value that is briefly out of date does no harm, and the system stays available.
• Most real systems use both. For example, payments in a relational database, and activity feeds in a distributed NoSQL database.

Using This in an Interview

If you say you will use a BASE database, expect a follow-up question: "What happens when two copies disagree?" Have a concrete answer, like last write wins, version vectors, or a merge rule for that exact data.

Also keep the two meanings of consistency separate. BASE relaxes the CAP kind, which is agreement between copies. It does not mean the data stops following its rules. Mixing up the two is a mistake that interviewers notice quickly.

Key Takeaways

• ACID is four promises about transactions: atomicity (all or nothing), consistency (rules always hold), isolation (no interference), and durability (committed means saved).
• Durability means a committed transaction stays saved, even after a crash or power failure.
• BASE means Basically Available, Soft state, and Eventually consistent.
• Eventual consistency promises that if no new updates are made, all copies eventually become identical.
• The C in ACID means following data rules. The C in CAP means copies agree on the newest value.
• During a network partition, a system either refuses to answer or answers with possibly outdated data.
• In a BASE database, the application must resolve disagreements between copies.

ACID protects correctness, and BASE protects availability. The next lesson, Strong vs Eventual Consistency, looks closely at what readers see in each case.

Practice Questions

Try each question first, then open the answer.

1. Account A holds 500 dollars, and account B holds 200 dollars. A transfer of 100 dollars takes the money from A, and then the server crashes before adding it to B. With atomicity, what are the balances after the database recovers?

<details> <summary>Show answer</summary>

A holds 500 dollars, and B holds 200 dollars. The transaction did not finish, so atomicity requires a rollback. The debit from A is undone. The total is still 700 dollars, so no money was lost. The customer can then try the transfer again.

</details>

2. One item is left in stock. Two customers try to buy it at the same moment, and both transactions read "stock = 1". Which ACID property prevents both purchases from succeeding?

<details> <summary>Show answer</summary>

Isolation. With a strict enough isolation level, or with a lock on the stock row, the two transactions cannot both update the stock count. One purchase succeeds and sets the stock to 0. The other transaction then sees 0, or fails and must retry, so the item is not sold twice.

</details>

3. A messaging app shows "message sent" after the database confirms the transaction. One second later, the server loses power. After the restart, is the message still stored?

<details> <summary>Show answer</summary>

Yes, because of durability. Once a transaction is committed, the change must survive crashes and power failures. The database wrote the change to its log on disk before confirming it, so it can recover the message after the restart.

</details>

4. A BASE database keeps three copies of a like count. A new like updates copy A at time 0, and copies B and C receive the update at about 300 ms. A reader reaches copy B at 100 ms. What does the reader see, and what happens if there are no more likes?

<details> <summary>Show answer</summary>

The reader sees the old count. At 100 ms, copy B has not received the update yet. This is eventual consistency. If no new updates arrive, all three copies hold the same count by about 300 ms. For a like count, this short delay does no harm.

</details>

5. During a network partition, a shopping cart service cannot reach some copies of the data. Should it refuse to update carts, or accept updates and resolve conflicts later? Would a bank transfer be different?

<details> <summary>Show answer</summary>

The cart service should accept updates, and the bank transfer should not. For a shopping cart, staying available matters most, and conflicts can be merged later, for example by keeping the items from both versions. For a bank transfer, an outdated or conflicting balance is not acceptable. So the bank should refuse or delay the transfer until the copies can agree.

</details>