Section 12: The Paper Was Right, the Product Was Different - Follow-up Feature Evolution: From Dynamo to DynamoDB

Executive Summary: The business comes back with three asks: a strongly consistent read at checkout, a change stream for analytics, and a cart that spans regions. The design takes two of them without touching its core: a per-partition change log of about 21 MB/s at peak, and asynchronous cross-region shipping that reuses the cart merge. It refuses the first: checkout gets its strong consistency from the order system instead. Then the epilogue. Dynamo worked, but Werner Vogels wrote in 2012 that its adoption inside Amazon was limited by its operational complexity. DynamoDB kept the partitioning and replication heritage and changed most of what a team would otherwise run itself: a Multi-Paxos leader per partition across 3 AZs, request routers instead of a client library, and built-in admission control. Cassandra, Riak and Voldemort complete the family tree.

Interviewer: "The cart has survived the holidays. Now three teams want something from it. Checkout wants a consistent read, analytics wants every change, and international wants the cart to follow customers across regions. Which do you build?"

You: "Two of them. The first is a request for a different consistency model, so I'll route it to a system that already has one. For each, I'll say whether it fits Decision 1 or fights it."

Ask One: A Strongly Consistent Read for Checkout

The checkout team's worry is real. Dana clicks "Place order" on their laptop seconds after merging D4 (Kindle + gift card). Could a read return something older?

With (3, 2, 2) and Section 8's read-your-writes coordinator choice, rarely. But "rarely" isn't a guarantee: Section 9 showed that sloppy quorum breaks the R + W > N overlap during failures. A truly linearizable read would need a single serialization point per key, a leader for partition 517. That leader is exactly what Decision 1 rejected: during the running example's four-minute partition, the side without it would refuse Dana's gift-card add.

You: "So the cart stays AP and checkout takes its consistency from somewhere else. The cart is a proposal. Checkout reads it, shows Dana the order summary to confirm, then re-prices every line and reserves inventory in the order system, which is strongly consistent because inventory and payment carry invariants a merge can't restore. That is Decision 1's flip trigger, applied to the right data."

Rejected alternative: a per-key leader on the cart instance. Flip trigger: if the cart itself started carrying an invariant, such as a reserved-stock hold, that hold moves out of the cart and into the strongly consistent store.

Quick check before moving on: