ACID vs BASE: What’s the Difference and When Does Each Apply?
Compare ACID and BASE database models — atomicity, isolation, eventual consistency, and when to pick each for scale.
Expected Interview Answer
ACID (Atomicity, Consistency, Isolation, Durability) describes transactions that are all-or-nothing, always valid, isolated from each other, and permanently saved once committed — the model traditional SQL databases use — while BASE (Basically Available, Soft state, Eventually consistent) describes systems that prioritize availability and accept that data may be temporarily inconsistent before it converges, the model most distributed NoSQL databases use.
ACID transactions guarantee that a multi-step operation either fully completes or fully rolls back (atomicity), that the database moves between valid states only (consistency in the ACID sense, different from CAP consistency), that concurrent transactions do not interfere with each other (isolation), and that a committed change survives crashes (durability) — ideal for workloads like payments where partial or incorrect state is unacceptable. BASE systems relax these guarantees in exchange for horizontal scalability and high availability: the system is basically available (it responds even during faults), its state can shift as updates propagate (soft state), and replicas eventually converge to the same value rather than being instantly consistent (eventually consistent). Neither is strictly better: ACID suits financial ledgers, inventory counts, and anything requiring strict correctness, while BASE suits high-throughput systems like social media feeds, shopping cart counts, or analytics events where a brief staleness window is an acceptable trade for scale and uptime. Many real architectures mix both, using ACID for the money-critical core and BASE for high-volume peripheral data.
- ACID gives strong correctness guarantees critical for financial and transactional data
- BASE enables horizontal scale and high availability across distributed nodes
- Choosing per-workload (not globally) lets each part of a system optimize for its actual needs
- Understanding both vocabularies helps justify database choices in design reviews
AI Mentor Explanation
ACID is like the official scorebook where a completed over is recorded fully and correctly or not recorded at all — no half-entered overs are ever left in the book, and once signed off, that entry is permanent even if the scorer’s pen runs out. BASE is like a live fan-run scoreboard app spread across thousands of phones, which updates optimistically as soon as a run is guessed to have happened and syncs to the true score moments later. The fan app is always showing something and never freezes, but it may briefly disagree with the official book before catching up. The choice between the two mirrors picking guaranteed correctness versus responsive, ever-available updates.
Step-by-Step Explanation
Step 1
Identify the correctness requirement
Ask whether partial or temporarily stale state is acceptable for this specific data (money, inventory vs counters, feeds).
Step 2
Map ACID to strict, transactional workloads
Use ACID (traditional SQL, or NoSQL with transaction support) for anything needing all-or-nothing correctness.
Step 3
Map BASE to high-scale, tolerant workloads
Use BASE-style NoSQL for workloads that value availability and horizontal scale over instant consistency.
Step 4
Combine both where needed
Use ACID for the money-critical core and BASE for high-volume peripheral data within the same system.
What Interviewer Expects
- Correctly expands both acronyms and explains each letter briefly
- Distinguishes ACID consistency from CAP consistency (different concepts, same word)
- Gives a concrete example of when to pick each model
- Recognizes real systems often mix both rather than picking one globally
Common Mistakes
- Saying BASE means “no guarantees at all” instead of “eventually consistent”
- Confusing the "C" in ACID with the "C" in CAP
- Claiming SQL is always ACID and NoSQL is never ACID (many NoSQL systems now offer ACID transactions)
- Picking one model for the entire system instead of per-workload
Best Answer (HR Friendly)
“ACID is the strict model traditional databases use, where a transaction either fully happens or doesn’t happen at all, which is essential for things like money transfers. BASE is a looser model many large-scale databases use, where the system stays up and responsive even during issues, but different parts of it might briefly show slightly different data before catching up. You pick ACID when correctness can’t be compromised, and BASE when you need to scale to huge traffic and a few seconds of staleness is fine.”
Code Example
def transfer_funds_acid(db, from_acct, to_acct, amount):
with db.transaction(): # atomic: all-or-nothing
db.execute(
"UPDATE accounts SET balance = balance - %s WHERE id = %s",
(amount, from_acct),
)
db.execute(
"UPDATE accounts SET balance = balance + %s WHERE id = %s",
(amount, to_acct),
)
# commit here; if either statement failed, the whole transaction rolls back
def increment_view_count_base(cache, event_queue, video_id):
# basically available: always accept the write locally
cache.incr(f"views:{video_id}")
# soft state / eventual consistency: propagate asynchronously
event_queue.publish("view_event", {"videoId": video_id})
# other regions will converge to the true total after processing the queueFollow-up Questions
- How does the "C" in ACID differ from the "C" in the CAP theorem?
- Can a NoSQL database offer ACID transactions? Give an example.
- What does “soft state” mean concretely in a BASE system?
- How would you design a shopping cart system using both ACID and BASE principles?
MCQ Practice
1. What does the "A" in ACID stand for?
Atomicity means a transaction either fully completes or fully rolls back, with no partial state left behind.
2. What best describes “eventually consistent” in a BASE system?
Eventual consistency means replicas may briefly disagree but converge to the same state once updates finish propagating.
3. Which workload is the strongest fit for ACID guarantees?
Money transfers require all-or-nothing correctness with no partial state, which is exactly what ACID transactions guarantee.
Flash Cards
What does ACID stand for? — Atomicity, Consistency, Isolation, Durability.
What does BASE stand for? — Basically Available, Soft state, Eventually consistent.
When to choose ACID? — When correctness cannot be compromised, e.g. financial transactions.
When to choose BASE? — When you need high availability and horizontal scale and can tolerate brief staleness.