Database Design • ACID vs BASEMedium⏱️ ~3 min
When to Choose ACID vs BASE
The decision hinges on whether correctness or availability is more critical, and whether your data model fits within consistency boundaries. Choose ACID when invariants must never be violated: financial ledgers (double entry bookkeeping requires atomic debits and credits), inventory systems at checkout (prevent overselling), entitlement checks (one seat per ticket), and any operation where lost updates or double spend are unacceptable. ACID within a single region or shard keeps coordination cheap (10 to 40 ms P99 versus 100 to 200+ ms cross region).
Choose BASE when low latency and high availability matter more than immediate consistency, and when your workload fits eventual consistency semantics. Read heavy catalogs with millions of products benefit from DynamoDB eventual reads (single digit ms, 3,000 reads per second per partition) versus Aurora reads through a single writer. Activity feeds, user profiles, session data, and Internet of Things (IoT) telemetry tolerate staleness and conflict resolution. Shopping carts can merge concurrent adds (union of items) without coordination.
Many systems need both. Use ACID for the source of truth write path (orders in Aurora, 15 ms commits) and BASE for read projections (order status in DynamoDB, 200 ms replication lag acceptable). This hybrid pattern appears at Amazon: Aurora for transactions, DynamoDB for scale, CDC streams connecting them. Microsoft follows similar patterns: Azure SQL Database for ACID, Cosmos DB for global low latency reads with tunable consistency.
Geography influences the choice. If users are global and local latency matters, BASE with multi region writes (Cosmos DB multi master, DynamoDB Global Tables) keeps writes under 10 ms locally while accepting async replication lag (under 1 second typical). If correctness across regions is required, ACID via Spanner accepts 100 to 200+ ms writes. The practical middle ground is ACID within a region, BASE across regions, and explicit cross region operations for rare global consistency needs.
💡 Key Takeaways
•ACID within a single region or shard costs 10 to 40 ms P99 and is feasible for user facing writes, but cross region ACID (Spanner) at 100 to 200+ ms is too slow for latency sensitive operations.
•BASE read projections from ACID sources via CDC scale reads 10x (single Aurora writer at 10,000 queries per second versus DynamoDB at 100,000 queries per second) while accepting 100 ms to 2 second staleness.
•Shopping carts are ideal for BASE because concurrent adds can merge (union of items) without coordination, unlike inventory decrement which requires ACID to prevent overselling.
•Multi region BASE (DynamoDB Global Tables, Cosmos DB multi master) keeps writes under 10 ms locally but requires application level conflict resolution (LWW drops writes, CRDTs avoid conflicts).
•Financial systems require ACID end to end: double entry bookkeeping demands atomic debit and credit within a transaction, making eventual consistency unacceptable even at 10x higher latency cost.
📌 Examples
Amazon checkout hybrid: Browse catalog from DynamoDB eventual (3ms reads, millions QPS), add to cart in DynamoDB session state (eventual, merge items), checkout writes order to Aurora ACID (15ms, prevent double charge), emit event to update DynamoDB order status (eventual, 200ms lag for status polling).
Netflix viewing history: Write watch progress to Cassandra with LOCAL_QUORUM (8ms within datacenter), replicate asynchronously cross region (under 1 second lag). Users tolerate seeing slightly stale progress when switching devices, prioritizing low latency over consistency.
Bank transfer requiring ACID: BEGIN; UPDATE accounts SET balance = balance minus 1000 WHERE id = 123; UPDATE accounts SET balance = balance plus 1000 WHERE id = 456; INSERT INTO ledger VALUES ...; COMMIT; All three writes must be atomic and durable, cannot use eventual consistency even for 10x speedup.