Amazon DynamoDB — Part 2: Internals & The Write Path

maang.io System Design Series

What is this?

Time to walk behind the warehouse wall. In Part 1 you handed a box to the concierge and it just… worked. Now we watch what actually happens: how the warehouse is carved into aisles, why every box is copied into three separate buildings, who the aisle foreman is that authorizes each change, and how a delivery becomes so durable that no fire, flood, or forklift accident can lose it.

Here's the thing that surprises people: DynamoDB is not the 2007 Dynamo paper. The original Dynamo used a consistent-hashing ring, vector clocks, sloppy quorums, and pushed conflict resolution onto the client — and it was eventually consistent, full stop. DynamoDB kept Dynamo's goals (availability, scale, predictable latency) but rebuilt the machinery. Under the hood it uses range-partitioned storage and Multi-Paxos-based replication with a single leader per partition — which is precisely why DynamoDB can offer strong consistency, something the original Dynamo couldn't. If you've read the Apache Cassandra internals, note the divergence: Cassandra stayed masterless; DynamoDB chose a leader per partition. That one decision explains most of what follows.

The one-line idea: A DynamoDB table is sliced into partitions; each partition is a replication group of three copies across three Availability Zones, coordinated by a Paxos-elected leader. Every write goes to the leader, lands in a write-ahead log, and is acknowledged the instant a majority (2 of 3) of replicas have durably recorded it. That's the whole durability story.