ACID vs BASE
Fast recall
Quick revision
Core answer
Awareness of the trade-offs between consistency and availability in distributed systems, and understanding that ACID vs BASE is a spectrum, not a binary choice
Thinking ACID and BASE are mutually exclusive for all scenarios, or that NoSQL always means BASE (many NoSQL systems offer tunable consistency)
Reference the CAP theorem, explain the trade-offs concretely, and give real-world examples where eventual consistency is acceptable (e.g., social media likes) vs where it's not (e.g., bank balances)
Interview-ready guide
Interview answer
ACID and BASE describe different concerns.
ACID gives properties for a transaction: all-or-nothing work, preservation of enforced rules, controlled concurrent visibility, and recovery of committed work. BASE is an informal label for distributed designs that stay broadly available while some state may be temporary or stale and later converge. They are not strict opposites and they are not SQL-versus-NoSQL categories.
CAP applies only during a network partition and asks whether a distributed operation favors linearizable consistency or availability.
For example, one system can use an ACID transaction for a ledger and an eventually consistent read model for an analytics counter. Choose per operation: define what must be atomic, how fresh reads must be, what happens during a partition, how conflicts resolve, and under what conditions replicas converge.
ACID vs BASE
Direct Answer
ACID describes guarantees for a transaction: atomicity, consistency, isolation, and durability. BASE is an informal way to describe designs that may accept temporary inconsistency while remaining available and converging later. They are not strict SQL-versus-NoSQL categories; one system can offer transactions for some operations and eventual consistency for others. Choose the guarantee required by each piece of data.
Code Example
-- One ACID transaction: debit and credit commit together.
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
A BASE-style example needs a distributed product rather than fake SQL: a view counter may accept writes in several regions and expose a temporarily stale total while replicas merge. The exact convergence and conflict rules come from that product's configuration.
Common Mistakes & Pitfalls
- Treating ACID and BASE as mutually exclusive products: One system can use a transaction for its source of truth and an eventually updated read model for a derived view.
- Mapping SQL to ACID and NoSQL to BASE: Relational and non-relational products expose different transaction and read guarantees by operation, topology, and configuration.
- Misstating CAP: CAP addresses linearizability versus availability while a network partition prevents required nodes from communicating. It is not a general speed comparison or a permanent two-letter product label.
Check your understanding
Answer these without looking back at the article.
- Can you explain the CAP theorem in simple terms?
- What does 'eventual consistency' mean for a user of a social media application?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.