Database Design • ACID vs BASEMedium⏱️ ~3 min
Consistency Latency Availability Tradeoffs
The choice between ACID and BASE fundamentally trades consistency, latency, and availability against each other. ACID coordination adds at least one network RTT plus disk flush time per commit. Within a region, this costs 10 to 40 ms P99. Cross region synchronous replication adds WAN RTT, pushing latencies to 100 to 200+ ms for intercontinental writes. During network partitions, ACID systems that require quorum become unavailable, blocking writes until quorum is restored.
BASE systems avoid this coordination tax by accepting writes locally and replicating asynchronously. DynamoDB eventual reads are single digit milliseconds because they read from any replica without waiting for replication. The cost is stale reads: a client might read old data until async replication completes (typically under 1 second for Global Tables but unbounded in general). DynamoDB offers strongly consistent reads within a region that add 2 to 5 ms to latency by reading from a quorum, demonstrating the per request tradeoff.
Azure Cosmos DB makes this tradeoff explicit with five consistency levels. Strong consistency provides linearizability but requires synchronous quorum reads, adding latency and reducing availability under partitions. Bounded staleness guarantees reads are at most K versions or T seconds old (e.g., 100,000 operations or 5 minutes), useful for scenarios like leaderboards where some lag is acceptable. Session consistency guarantees read your writes and monotonic reads for a session token, enabling low latency (single digit ms) while preventing confusing user experiences like profile updates disappearing.
Real systems choose per operation. Amazon retail uses eventual consistency for catalog browsing (low latency, high availability) and strong consistency for checkout inventory checks (prevent overselling). Microsoft uses session consistency as the default for Cosmos DB because it provides intuitive semantics (users see their own writes) at near eventual latency, with strong consistency reserved for critical reads like account balance checks.
💡 Key Takeaways
•DynamoDB strongly consistent reads add 2 to 5 ms versus eventual reads within a region, demonstrating per request consistency cost without requiring global ACID
•Cosmos DB bounded staleness allows tuning staleness window (e.g., 100,000 operations or 5 minutes lag) to balance freshness with latency for time series or leaderboard workloads
•Session consistency provides read your writes and monotonic reads at near eventual latency (single digit ms) by routing reads to replicas with session token, preventing user visible inconsistencies
•Cross region strong consistency in Cosmos DB adds WAN RTT (60 to 150 ms intercontinental) and reduces write availability SLA to 99.99% versus 99.999% for eventual due to partition sensitivity
•Hot partition tail latency in BASE systems can spike from 10 ms to 200+ ms when a single key exceeds approximately 1,000 writes per second, eroding the latency advantage
📌 Examples
Amazon checkout: Browse catalog with eventual consistency (3ms reads), add to cart with session consistency (5ms, see own cart), finalize order with strong consistency for inventory decrement (15ms, prevent overselling)
Cosmos DB bounded staleness for leaderboard: Set staleness to 100,000 operations or 5 minutes. Top scores update within 5 minutes worst case, good enough for game leaderboards, avoids strong consistency cross region cost of 100+ ms
DynamoDB Global Tables multi region: Write in us-east-1 (5ms local), replicate to eu-west-1 asynchronously (800ms typical). User in Europe reads stale data briefly but system remains available even if us-east-1 fails completely