Section 11: The Doors You Left Open - Follow-up Feature Evolution

Executive Summary: This section runs the final test of the design: evolution under product pressure. The interviewer plays product manager and asks for four features in sequence — emoji reactions, a "who liked this" list, like notifications, and likes as a ranking signal — and the design must absorb each one without demolition. Three land as small, additive changes because the likes ledger was the source of truth all along. The fourth, notifications, is the moment the event stream finally earns its seat — resolving, on schedule, the Kafka question Section 7 deliberately left open. The section's transferable lesson: extensibility lives in the data model, not in speculative components.

Fifteen minutes left, and the interviewer changes costumes. The marker goes down, the product-manager voice comes out: "Launch went great. Now the roadmap: reactions like the big apps, a list of who liked each post, a notification when someone likes your reply, and the ranking team wants likes as a signal. What changes?"

This is not feature trivia. It is the closing audit of every decision you made in the previous hour, and where the two failure archetypes get their final grades: the Dismissal's counter-only table has no answer to "who liked this" at all, while the Citadel's day-one Kafka pipeline is about to be revealed as the right component bought at the wrong time. Your answer, feature by feature, should sound almost boring — and that boredom is the point.

Key Insight: Interviewers use follow-up features to test whether your extensibility was structural or speculative. Structural extensibility means the source of truth already contains the information the new feature needs. Speculative extensibility means you built machinery in advance and hoped. The first costs nothing until it pays out; the second costs operations every day whether it pays out or not.

Reactions: Six Emoji, One Attribute

Product wants the like button to become six reactions — the heart joined by laugh, wow, sad, angry, fire. The naive fear is a remodel; the actual change is an attribute.

The ledger keeps its key: one row per (post_id, user_id). The row gains a reaction attribute, defaulting to like for every existing row. The uniqueness constraint — the same conditional insert that absorbed Priya's double-tap in Section 5 — now enforces one reaction per user per post, so switching from heart to fire is an update to the existing row, not a second row. The counter stops being a single number and becomes a small map (or six co-located counter rows under the same partition key): {like: 41,900, fire: 310, wow: 88, ...}. The API barely moves: PUT /posts/{postId}/like grows a one-field body naming the reaction, and DELETE is untouched — the state-setting semantics from Section 4 carry over verbatim, retries and all.

What does not change is the part that took two deep-dive sections to get right. The hot-post path folds per-reaction increments in the same 100ms buffer and flushes +N per reaction; the display rules still round at 10K; reconciliation still recounts from the ledger, now grouped by reaction. The rejected alternative — a separate reactions table beside the likes table — doubles the write paths and forces two tables to agree about one user intent. The flip trigger: if product ever allows multiple simultaneous reactions per user per post, the sort key must widen to (user_id, reaction) — a real migration, which is exactly why you ask product that question before writing a line.

The rollout is the standard three-step — expand (write the new attribute), backfill (stamp like onto history), contract (retire the old read path) — and naming it signals you have shipped schema changes against live traffic.

Quick check before moving on: