Mako: Speculative Distributed Transactions with Geo-Replication
summary
A transactional key-value store called Mako is built that decouples execution from geo-replication, running speculative 2PC locally and replicating decisions to Paxos in the background. It reports 3.66M TPC-C tps on Azure with 10 shards × 24 threads (8.6× faster than prior geo-replicated systems). Selective rollback uses vector clocks and watermarks to avoid cascading aborts after a shard crash. Median latency is ~60 ms (≈50 ms for one RTT replication), and failure tests preserve most throughput.
AI-written summary · about
chapters (14)
- 0:00Mako introduction and goals
- 1:03Transactional systems compared
- 2:29RDMA limitations in geo-replication
- 3:13Classic geo-replication design
- 4:14Decoupling replication from execution
- 5:172PC and recovery problems
- 6:42Epoch-based recovery challenges
- 9:16Vector clocks for recovery
- 12:33Mako execution flow stages
- 13:41Evaluation setup and metrics
- 14:25Scalability comparisons
- 15:31Handling single-shot failures
- 16:14Latency breakdown and optimizations
- 16:58Summary and Q&A
related talks
37mGeo-Replicated Transactions in 1.5RTT
54mEvolving Transactions in Apache Cassandra
01h 14mThe hitchhiker's guide to distributed transactions
14mRetrofitting High Availability Mechanism to Tame Hybrid Transaction/Analytical Processing
40mDistributed Commit Log: Application Techniques for Transaction Processing
47mBeing transactional in 2019 - what does this actually mean?
24mUsing a Distributed Key-Value Store
01h 00mDistributed transactions implementation trade-offs