Section 12: The Doors You Left Unlocked - Follow-up Feature Evolution

Executive Summary: The store works, the pager is quiet, and the tenants arrive with wishlists. This section walks the five requests every successful KV platform eventually hears — range scans, secondary indexes, change streams, cross-region active-active, and transactions — and prices each against the day-one design. Two are extensions the architecture absorbs; two walk through doors earlier sections deliberately left unlocked; one flips a foundation. The 401 skill on display: knowing which is which before you say yes, and saying the price out loud.

Six months after launch, Mira's platform is a victim of its own success. The checkout team's cart:8842 has ten million siblings, the flags team's config:flags hums along behind its coordinator cache, and the roadmap review opens with a sentence every infrastructure owner learns to fear: "This is great — we just need a few more features." The interviewer plays this card in the final fifteen minutes, and it is not small talk: does the candidate know which parts of the design were load-bearing decisions and which were merely defaults? The Paper Reciter says yes to everything and gestures at "adding a layer." The passing candidate reads out the flip triggers written down on day one.

Key Insight: Every rejected alternative in Sections 5 through 9 came with a named flip trigger — the future requirement under which the rejection reverses. Feature evolution is where those triggers fire. A candidate who priced the flips in advance evolves the system; a candidate who didn't rebuilds it.

Range Scans: The Request That Flips a Foundation

The analytics team asks first: "Give us all keys with prefix cart: — we want to scan carts." This is the one request the day-one design cannot absorb, because Section 5 chose consistent hashing precisely to destroy key locality. Adjacent keys hash to opposite sides of the ring; a prefix scan touches all 64 nodes and all 16,384 tokens, turning one query into a cluster-wide scatter-gather. The hash ring isn't missing a feature — it is the negation of this feature.

Honoring the request for real means range partitioning: keys stored in sorted order, partitions owning contiguous key ranges, scans walking a handful of partitions sequentially. But ranges bring back everything hashing solved — sequential-key hotspots, and partitions that must split and merge as data skews. Split/merge requires authoritative metadata: which ranges exist, who owns them, mid-split state. Gossip's eventually consistent rumor mill cannot carry that safely, so the membership flip arrives in the same breath: a consensus-backed control plane (etcd/ZooKeeper-class, the HBase and Spanner lineage) earns the seat it was denied in Section 7. Two day-one decisions reverse together — they were always the same door.

The middle path is what DynamoDB shipped: hash on a partition key, sort on a local sort key. cart:8842#item:17 hashes by cart, sorts by item — scans within one key's family, no global ordering, ring intact. For most tenants who say "range scan," this is what they need, at a fraction of the price.

Quick check before moving on: