The Two Promises
In 2012, Instagram had a problem. Their PostgreSQL database gave them perfect ACID consistency, but writes were getting slow under the weight of 25 million users all liking, commenting, and following simultaneously. They needed to decide which parts of their system truly needed perfect consistency and which parts could relax, the classic ACID vs BASE trade-off that every growing platform eventually confronts.
This is the fundamental tension: ACID says 'your data will always be perfectly consistent, even if the server crashes mid-operation.' BASE says 'your data will eventually be consistent, but in the meantime, the system stays available and fast.' Every data architecture is a blend of both.
The ACID vs BASE Spectrum:
ACID (strong consistency) BASE (eventual consistency)
|========|=========|===========|============|
^ ^ ^ ^ ^
| | | | |
Bank Inventory Shopping Social Analytics
transfer at cart media dashboard
checkout likes
<-- slower, safer faster, available -->
<-- coordination cost minimal coordination -->ACID: When Every Bit Matters
ACID (Atomicity, Consistency, Isolation, Durability) is the philosophy of traditional relational databases. Every transaction is an all-or-nothing unit.
-- ACID bank transfer example
BEGIN TRANSACTION;
-- Atomicity: both succeed or both fail
UPDATE accounts SET balance = balance - 500 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 500 WHERE id = 'bob';
-- Consistency: database checks constraint
-- CONSTRAINT: balance >= 0 (prevents overdraft)
-- If Alice only has $300, the constraint fails,
-- and BOTH updates are rolled back automatically
COMMIT;
-- Durability: once COMMIT returns, the data is on disk
-- even if the server loses power 1ms laterThe cost: achieving these guarantees requires coordination. When you write data, the database must write to the WAL (write-ahead log), check constraints, manage locks, and coordinate with replicas. This takes time and limits throughput.
BASE: When Speed Beats Precision
BASE stands for:
Basically Available - the system responds to every request, even if the data might be slightly stale
Soft state - the state of the system can change over time, even without new input (as replication catches up)
Eventually consistent - if you stop writing, all replicas will eventually converge to the same state
Think of BASE like a chain of stores updating their inventory. When a store in Chicago sells the last red jacket, it takes a few seconds for the New York store's website to show it as out of stock. During those seconds, New York shows stale data. But eventually, both stores agree.
Eventual consistency timeline:
Time 0ms: User posts a tweet
Primary DB: tweet saved
Replica US-E: [not yet]
Replica EU: [not yet]
Time 50ms: Replication starts
Primary DB: tweet saved
Replica US-E: tweet saved (50ms replication lag)
Replica EU: [not yet]
Time 150ms: All replicas converge
Primary DB: tweet saved
Replica US-E: tweet saved
Replica EU: tweet saved (150ms replication lag)
During the 150ms window, a user reading from the EU
replica would NOT see the tweet. After 150ms, everyone
sees the same data. This is "eventual" consistency.Real-World Trade-off Map
Operation Consistency Why
---------------------- ----------- --------------------------------
Bank transfer ACID Money must not appear/disappear
Flight seat booking ACID Cannot oversell seats
Inventory at checkout ACID Must verify stock before charging
User registration ACID Email uniqueness must be enforced
---------------------- ----------- --------------------------------
Social media likes BASE 547 vs 549 - nobody notices
News feed BASE Seeing a post 2 sec late is fine
Shopping cart BASE Brief lag across devices is OK
Leaderboard BASE Approximate ranking is acceptable
Analytics dashboard BASE Near-real-time is good enough
Search index BASE Few seconds of indexing lag is OKWhy Not Always Use ACID?
Because ACID across distributed systems is extremely expensive:
A distributed ACID transaction touching 5 services might take 500ms vs 5ms for an eventually consistent write
ACID requires coordination (locks, two-phase commit) which creates bottlenecks under high load
ACID with strong consistency across regions means writes wait for cross-continent round trips (100-200ms per region)
Under network partitions, ACID systems must refuse writes (sacrificing availability) to maintain consistency
The Numbers
Single-region ACID write: ~5-10ms
Multi-region ACID write (2PC): ~200-500ms (40x slower)
Eventually consistent write: ~2-5ms
Replication lag (same region): ~1-10ms
Replication lag (cross-region): ~50-200msThe Practical Pattern: Mix Both
The best architectures are not purely one or the other. They identify which operations REQUIRE perfect consistency and use ACID there. Everything else gets the speed and availability benefits of BASE.
E-commerce checkout flow:
1. Add to cart --> BASE (Redis, fast, ephemeral)
2. Browse products --> BASE (read from replica, may be stale)
3. View cart total --> BASE (client-side calculation is fine)
4. Click 'Place Order' --> ACID begins here!
a. Verify inventory --> ACID (SELECT FOR UPDATE on stock table)
b. Charge payment --> ACID (idempotent payment API)
c. Create order --> ACID (single PostgreSQL transaction)
d. Decrement stock --> ACID (same transaction as order)
5. Send confirmation --> BASE (async email, retry on failure)
6. Update search index --> BASE (eventual consistency is fine)ACID & BASE
Interview Tip
When an interviewer asks about consistency, say: 'I would not make the entire system ACID or eventually consistent. I would classify each operation by its consistency requirement. Financial operations get ACID. User-facing counters and feeds get eventual consistency. The boundary between ACID and BASE is where I put message queues - they bridge the gap between the two worlds.' This shows mature architectural thinking.
Key Takeaway
ACID guarantees perfect data every time but limits speed and availability at scale. BASE accepts temporary inconsistency but keeps the system fast and available. Neither is universally better - the art of system design is knowing which guarantee each piece of your system needs.