Section 2: Availability Is the Product - Requirements (Functional & Non-Functional)

Executive Summary: Section 1 narrowed the prompt to a primary-key store that must never refuse a write. This section turns that into a contract. It offers get and put by key, per-service (N, R, W), surfaced conflicts and one-node-at-a-time growth. It promises p99.9 ≤ 300 ms at peak with a mean around 10 ms, accepts at least 99.99% of cart writes, and survives the loss of a whole data center at peak. Underneath it is a business decision: during a partition neither side refuses, and the price is read-time reconciliation.

The interviewer leans back. "'Never say no' is a slogan. Give me requirements I could write a test against."

You: "Three lists: what it does, what it guarantees in numbers, and what it refuses to build. One framing first: here, availability is the product. Every requirement below either buys write availability or pays for it."

Functional requirements: what a service can do with it

• get(key) returns the object under a key, or all conflicting versions, plus an opaque context. Section 4 defends the list.
• put(key, context, object) stores a new version. The context tells the store which versions this write supersedes.
• Conflict surfacing. When Dana's laptop and phone edit cart:7731 concurrently on opposite sides of a partition, the store keeps both versions for the next reader. The store detects; the application resolves.
• Per-instance tuning. One codebase, many instances, each with its own N, R, W and storage engine. The cart instance runs (3, 2, 2), the common configuration in the 2007 paper. A read-heavy instance can run (3, 1, 3).
• Incremental scalability. An operator adds one node at a time, and only a small slice of data moves.
• Symmetry. Every node has the same responsibilities. No master, no leader.
• Decentralization. No central coordinator sits on the request path or in failure handling.
• Heterogeneity. A node with twice the capacity takes roughly twice the partitions, so hardware generations can mix.

Interviewer: "Symmetry sounds like aesthetics. Why is it a requirement?"

You: "Because a special node is a node that can refuse. If one master orders writes for a key range, then a partition between me and that master is a refused add. Symmetry is how 'never say no' shows up in the architecture."