Database Design • ACID vs BASEEasy⏱️ ~3 min
BASE Properties: Availability Through Eventual Consistency
BASE systems prioritize availability and low latency by relaxing immediate consistency guarantees. Basically Available means the system accepts reads and writes even during partial failures. Soft State allows replicas to temporarily diverge without coordination. Eventual Consistency guarantees that replicas converge over time through asynchronous replication and anti entropy processes, but offers no bound on when.
The performance win is dramatic. Amazon DynamoDB delivers single digit millisecond P50 reads and sub 20 ms P99 reads within a region because it avoids coordination on the critical path. Writes are append local operations that replicate asynchronously, then background processes (Merkle tree anti entropy, hinted handoff) reconcile divergence. A single DynamoDB partition sustains roughly 1,000 write capacity units per second or 3,000 read capacity units per second before automatic splitting, enabling horizontal scale.
The cost is application complexity. Without coordination, conflicts arise when multiple replicas accept concurrent writes. DynamoDB Global Tables use last writer wins (LWW) based on timestamps for conflict resolution, which can silently drop older writes if clocks are skewed. Applications must design for idempotency, use conditional writes with version checks (ETags), or employ Conflict free Replicated Data Types (CRDTs) for operations like counter increments. Shopping cart merges, profile updates, and activity feeds can tolerate temporary inconsistencies, making BASE ideal for these workloads.
Most production systems blend ACID and BASE strategically. Amazon uses DynamoDB for high scale catalog reads and session data (BASE), while using Aurora for order transactions and payment processing (ACID). Microsoft Azure Cosmos DB offers five consistency levels from strong to eventual, letting each request choose its point on the consistency latency availability frontier.
💡 Key Takeaways
•DynamoDB delivers single digit ms P50 and sub 20 ms P99 reads within a region by avoiding coordination, with eventual consistency typically converging in under 1 second for Global Tables
•A single DynamoDB partition handles approximately 1,000 write units per second or 3,000 read units per second before splitting, enabling linear horizontal scale
•Last writer wins conflict resolution drops older writes when clocks are skewed or concurrent updates occur, requiring application level idempotency keys and conditional writes
•Hot partitions (popular product keys) saturate partition throughput and spike P99 latencies to 200+ ms, requiring key salting or write sharding with background aggregation
•Availability Service Level Agreement (SLA) reaches 99.999% for DynamoDB Global Tables (52 minutes downtime per year) versus 99.99% for standard tables (52 minutes per year)
📌 Examples
Shopping cart with BASE: User adds item to cart in US region (replica A writes locally in 5ms), then immediately views cart from EU region (replica B) but sees old cart for 800ms until replication completes. User experience tolerates this temporary inconsistency.
DynamoDB conditional write for idempotency: PutItem with ConditionExpression 'attribute_not_exists(requestId)' ensures duplicate retries don't double charge, returning ConditionalCheckFailedException on conflict
Azure Cosmos DB session consistency: Client writes profile update in West US with session token, then reads from East US replica using that token to guarantee seeing own write within 10ms, while other users may see stale data