Database DesignACID vs BASEMedium⏱️ ~3 min

Consistency Latency Availability Tradeoffs

The Fundamental Trade-off

ACID vs BASE fundamentally trades consistency, latency, and availability against each other. ACID coordination adds at least one network round-trip plus disk flush per commit. Within a region: 10-40ms at P99. Cross-region synchronous replication adds wide-area network latency: 100-200ms for intercontinental writes. During network partitions, ACID systems requiring quorum become unavailable, blocking writes until quorum is restored.

BASE Latency Advantage

BASE systems avoid coordination by accepting writes locally and replicating asynchronously. Eventual reads are single-digit milliseconds because they read from any replica without waiting. The cost is stale reads: a client might read old data until async replication completes (typically under 1 second but unbounded in general). Strongly consistent reads add 2-5ms by reading from a quorum, demonstrating the per-request trade-off.

Tunable Consistency

Some databases offer tunable consistency levels. Strong consistency (linearizability: every read sees the latest write) requires synchronous quorum reads, adding latency and reducing availability. Bounded staleness guarantees reads are at most K operations or T seconds old, useful for leaderboards where some lag is acceptable. Session consistency guarantees read-your-writes (you see your own updates) and monotonic reads (you never see data go backward) for a session, enabling low latency while preventing confusing user experiences.

Per-Operation Choice

Production systems choose per operation. Use eventual consistency for catalog browsing (low latency, high availability) and strong consistency for checkout inventory checks (prevent overselling). Session consistency works well as default: users see their own writes at near-eventual latency, with strong consistency reserved for critical reads.

💡 Key Takeaways
ACID adds 10-40ms P99 within region; cross-region adds 100-200ms due to network latency and consensus protocols
Strongly consistent reads add 2-5ms versus eventual reads by requiring quorum, showing per-request cost
Session consistency: read-your-writes and monotonic reads at near-eventual latency, prevents users seeing their updates disappear
Choose consistency per operation: eventual for browsing, strong for inventory checks, session for user-facing updates
📌 Interview Tips
1Explain linearizability simply: every read sees the most recent write across all clients, as if there was one copy of the data
2Describe bounded staleness: reads guaranteed at most N operations or T seconds behind, useful for leaderboards accepting brief lag
3For checkout flow: browse with eventual (3ms), add to cart with session (5ms, see own cart), finalize with strong (15ms, prevent oversell)
← Back to ACID vs BASE Overview