Section 10: Growth Without Demolition - Follow-Up Feature Design: Sharing & History

Executive Summary: This section extends the shipped MVP with the features the interviewer inevitably requests — color history, public and curated sharing, team palettes — without breaking a byte of the original contract. Each feature is analyzed as a new access pattern first, then given the storage shape that pattern demands: history through single-table item collections behind a sort key, sharing through a token-keyed table with an unauthenticated read surface secured by unguessability. We close with the mechanics of live-system evolution — the expand-migrate-contract procedure — and the pre-named trigger that finally admits a queue into the architecture.

The interviewer's posture softens; the adversarial phase is over, and the generative one begins. "The tool ships, and people love it. Product wants three things: users see their color history, anyone can share their color with a link, and teams want shared palettes. Evolve your design." The trap here has two jaws, mirror images of every trap before it. One candidate discovers their MVP requires demolition — the schema can't grow, the API must break, version two starts from a blank page. The other candidate reveals, sheepishly, that they secretly built all of this already — meaning Section 2's scope discipline was theater. The winning demonstration is different from both: watching each feature arrive through a door that was deliberately left unlocked, at the moment it was needed and not before.

Key Insight: The Staff-level distinction is between building the future (speculative, usually wasted) and not blocking it (deliberate, always cheap). Section 5 left two doors unlocked and named them. This section walks through them — and the walking is the demonstration.

Feature One: Color History - The Sort-Key Door Opens

Run the discipline before the design: what is history, as an access pattern? Writing stays one save at a time. Reading becomes two questions — "my current color" (unchanged) and "my recent colors, newest first" (new). A list, keyed by owner, ordered by time. That is precisely what a partition-key-plus-sort-key table shape exists to serve:

The partition becomes an item collection: a CURRENT item — byte-for-byte the record already served, so the existing GET does not change — and timestamped HIST#… siblings appended by each save. The write path grows from one PutItem to an atomic pair:

// One save = replace CURRENT + append one history item, atomically.
// TransactWriteItems guarantees history can never disagree with the present.
await store.transactWrite([
    replaceCurrent(userId, color, expectedVersion),        // honors If-Match as before
    appendHistory(userId, color, timestamp),               // HIST#<iso-timestamp>
    trimHistoryBeyond(userId, MAX_HISTORY_ENTRIES = 20),   // bounded, by design
]);

This is textbook single-table design — the discipline Rick Houlihan's re:Invent talks made famous — built for exactly this evolution: a new access pattern absorbed by new item shapes in the same table. Two rules keep history honest. Bound it: twenty entries, trimmed on write, because unbounded "history" quietly converts 300 bytes per user into a cost and compliance conversation nobody scheduled. Add, never mutate: GET /api/v1/colors/history and POST /api/v1/colors/restore are new doors on the building; the original two endpoints keep their exact contracts, and day-one clients never notice the building grew (NFR Connection: Section 4's evolution rule, honored under live fire).