13.2. Distributed Key-Value Store: DynamoDB / Cassandra
Dynamo — the 2007 Amazon paper, distinct from the DynamoDB product it inspired — is the origin story of the AP database: a system that chooses availability over consistency and builds everything else around that choice. Consistent hashing for partitioning, quorums for tunable consistency, and vector clocks (later, largely, last-write-wins) for conflict resolution all trace to it. This chapter covers that lineage in DynamoDB and Cassandra, their data models, and the hot-partition problem that their design makes possible.
Topics Covered
Section titled “Topics Covered”- 13.2.1. SLA-Driven Design: The P99 Latency Guarantee: Explains how a hard P99 latency SLA drove Dynamo’s every design decision toward predictability.
- 13.2.2. DynamoDB’s Data Model: Partition Key + Sort Key: Covers DynamoDB’s partition-key-plus-sort-key model and how it forces access-pattern-first design.
- 13.2.3. Cassandra’s Consistent Hashing Ring: Explains Cassandra’s consistent hashing ring, token allocation, and virtual-node distribution.
- 13.2.4. Vector Clocks in the Dynamo Paper: Conflict Resolution and Its Legacy: Covers vector clocks in the original Dynamo paper and why the industry largely moved to last-write-wins.
- 13.2.5. The Hot Partition Problem: A Real-World Case Study: Analyzes the hot-partition problem as a real-world case study in access-pattern-induced skew.