Calvin: Fast Distributed Transactions for Partitioned Database Systems
Alexander Thomson, Thaddeus Diamond, Shu-Chun Weng, et al.2012SIGMOD 2012
Read it on doi.org(opens in a new tab)Why this one
Read this after Spanner and The Google File System if you want the other fork in the road for distributed databases. Spanner spends machinery on making time trustworthy enough to serialize transactions across replicas. Calvin instead says: stop discovering the order while locks are held. Put every transaction into a global log first, then make execution a deterministic consequence of that log. The trick is easy to say and hard to internalize because it moves the hard part out of the storage engine and into sequencing, batching, and knowing read and write sets early. People often remember Calvin as just 2PC avoidance, but the deeper lesson is architectural: if all replicas already agree on the input order, concurrency control becomes replay, not negotiation. Worth your evening because it gives you a clean mental model for when coordination is paid upfront and when it is paid in the hot path.
What to take away
- Calvin orders transactions before execution, so replicas can run the same work without negotiating commit order.
- The design works best when transaction read and write sets are known before locks are acquired.
- Its trade is clear: pay for sequencing and determinism to remove distributed commit from the critical path.
Reads with
- Spanner: Google's Globally-Distributed Database
the contrasting fork: serialize with trusted time instead of a predetermined transaction log
- In Search of an Understandable Consensus Algorithm
calvin's sequencer needs replicated agreement before storage can just replay
- Building a Replicated Logging System with Apache Kafka
shows the log as infrastructure once ordering becomes the system's real control plane