Database DesignACID vs BASEHard⏱️ ~3 min

Failure Modes: When ACID and BASE Break Down

ACID Failure: Write Skew

Snapshot isolation (transactions see consistent snapshots) is vulnerable to write skew: two transactions read the same snapshot, pass checks, both commit, violating an invariant. Example: two transactions check at least one doctor on-call, both see two, both remove one, leaving zero. Fix: serializable isolation (transactions appear sequential) or explicit locking, adding 20-50% latency in high contention.

BASE Failure: Clock Skew

Last-writer-wins (LWW) uses timestamps, but clock skew can drop valid writes. If one replica clock is 2s ahead, a write at real-time T+2 can be dropped for a write at T with skewed later timestamp. Fix: logical clocks (counters per operation) or vector clocks (tracking causality), or application-level versioning with conditional writes.

Monotonic Read Violations

Eventual consistency shows "time travel": client reads fresh data, reads again, sees older data (hit stale replica). Session consistency pins reads to replicas at or ahead of a session token, preventing this but requiring sticky routing.

Hot Partition Problem

Hot partitions degrade both models. A viral item hits 1K writes/sec partition limit, pushing P99 from 10ms to 200ms+. ACID suffers lock queues. Fix: key salting or write sharding.

💡 Key Takeaways
Write skew in snapshot isolation: two transactions both pass checks on same snapshot and commit, violating invariants like zero on-call
Clock skew with LWW: a 2-second clock difference can permanently lose a valid write to an older one with skewed timestamp
Monotonic read violations: user sees newer data then older data, breaking trust; session consistency prevents this via sticky routing
Hot partitions spike P99 from 10ms to 200ms+ in both models; fix with key salting or write sharding
📌 Interview Tips
1Explain write skew with on-call example: both see 2 doctors on-call, both remove 1, result is 0 on-call (invariant violated)
2For clock skew, describe vector clocks: each replica tracks a counter per replica, enabling causal ordering without synchronized clocks
3Hot partition fix: shard key into item_id_0 through item_id_9 (write sharding), aggregate reads from all shards
← Back to ACID vs BASE Overview