Section 1: The Cart That Must Never Say No - Problem Understanding & Clarifications

Executive Summary: The prompt mentions disks failing, links flapping and a data center going dark, and most candidates hear "build a strongly consistent replicated database". This section shows a better first ten minutes. We break the prompt into what, who, why and how. Then five clarifying questions each remove a large piece of database machinery: no joins, no large objects, no multi-key transactions, no hostile nodes, and no single shared cluster. What remains is a primary-key store, run as many separately tuned instances, with one requirement that shapes everything after it: an "add to cart" must succeed even if it later conflicts with another write. From that point on, consistency is something we reconcile after the fact, not something we enforce up front.

The interviewer reads the prompt aloud:

"It's 2006. Amazon's shopping cart must accept 'add to cart' even when disks fail, network links flap, or a whole data center goes dark. Design the storage system behind it — and since other teams will reuse it, tell me what you'd let each of them tune."

Here's the trap. "Storage system" plus "a data center goes dark" sounds like a call for a replicated relational database with a primary, synchronous backups and automatic failover. A candidate who goes that way ends up with a design that does the one thing the prompt forbids: when the network splits, the side without the leader refuses writes, and a shopper there clicks "add to cart" and gets an error.

Key Insight: The important word in the prompt is must. "Must accept 'add to cart'" is a business requirement, not a vague wish for high availability. Every refused add is a sale that may not happen. Once you treat "never refuse a write" as fixed, most of the architecture follows from it.

A note on scope. The course's Distributed Key-Value Store module builds a generic Dynamo-class store from first principles: the ring, quorums, the storage engine, conflict handling. This module is a case study of the real system, Amazon's Dynamo as described in the 2007 paper. We make Amazon's decisions, for Amazon's reasons, and note which ones it later reversed.

Decomposing the Prompt

Before asking anything, map the territory out loud:

• What it does: Reduce it to verbs. The cart service reads a cart and writes a cart, always by one key. That's get and put by primary key.
• Who uses it: Services, not people. The first user is the cart service. "Other teams will reuse it" means session state, preferences, best-seller lists and more will follow. Our callers are programs we can ship a library to.
• Why it exists: Revenue and trust. A shopper who adds a Kindle and later finds it missing doesn't file a bug report. They just buy less. A briefly stale cart costs little, because the shopper looks at it again before checkout.
• How it's used: Amazon renders a page by calling many services, and each service calls its own storage. The cart badge appears on almost every page, so this store sits under the whole page-rendering path, and its slowest responses become the page's slowest responses.