Beyond Eventual Consistency
summary
Starbucks rebuilds rewards and mobile-order systems because Cassandra’s eventual consistency causes stale reads that lose sales and points. Alternatives compared: Google Spanner’s true time and 5‑nines SLA, Microsoft Cosmos’s tunable consistency, CockroachDB (open source, Jepsen‑compliant but ~200 ms read cost), and FaunaDB claiming single‑phase commit with 10 ms latency, serializability, Raft ordering and row‑level auth; Fauna runs a working POC at Starbucks and delivered a patch for a found bug.
AI-written summary · about
chapters (24)
- 0:00Intro
- 3:46Dont write complex software
- 5:11Cassandra
- 10:09Cap Theorem
- 12:06Databases
- 12:41Eric Brewer
- 13:51Optimizing for the wrong case
- 14:16Does anyone have a database that never goes down
- 14:59Daniel Abadi
- 19:12Data Management Taxonomy
- 19:36Acid Properties vs Consistency in the Cap Theorem
- 20:29Consistency in a Distributed Database
- 23:47Serializability
- 25:47Data Semantics
- 27:17CA IQ
- 28:03Amazon Aurora
- 32:24Cosmos DB
- 34:06Cassandra DB
- 41:04Cockroach TV
- 41:38NTP
- 42:48Fawna
- 47:46Not a mature solution
- 53:58Datastacks Cassandra
- 55:21Buying out FaunaDB
related talks
46mBeyond Eventual Consistency
18mNoSQL, YesCosmos: Build that Eventually Consistent Application using Azure Cosmos DB
13mThe ACID BASE Conundrum
33mGoogle Cloud Spanner: Global consistency at scale
47mGoogle Cloud Spanner: Global consistency at scale
22mOrder And Consistency At Scale
43mEffective Eventual Consistency with Actor Models + Amazon Web Services
08mWhen Worlds Collide: Frontend vs Database