</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Section 11: Growing Without Demolition - Follow-up Feature Evolution

Executive Summary: The interviewer reads out the roadmap to see whether the design bends or breaks. For six features we name what changes, what stays, and which door an earlier section left open. Two decisions flip on purpose: the URL scheme (D5) and the draft store (D2). The publish pipeline and the one-cached-HTML read path survive all six.

The interviewer turns the page: "Say this ships and it works. Product has six things for next year. Walk me through how each one lands, and tell me what you'd have to tear down."

"First, how I'll judge each one. Three things carry this design: immutable revisions plus a pointer flip, so readers only see finished revisions; one cached HTML per URL for everyone, personal state in /me; and the outbox as the only source of side effects, so any new reaction to a publish is just another consumer. A feature that keeps all three is cheap. One that breaks any of them is expensive, and I'll flag it."

Key Insight: Feature evolution is scored on predicting cost before building. Naming the invariants first turns six open questions into six checks against one list.

Six roadmap features growing from the core of draft, revisions, pointer, outbox and one cached HTML, each labelled with what it changes

1. Multi-author Publications

Section 5's data model already has publication_members(publication_id, user_id, role), holding only the owner today. Team blogs fill in the roles: owner (settings, members), editor (review and publish anyone's post), writer (draft and submit). Say Maya invites two colleagues to write for Boring Infrastructure.

What changes is the workflow. A writer submits a specific draftVersion, as publishing does, and the editor reviews exactly that version. POST /v1/posts/{postId}/publish and Section 10's server-side draft authorization now check "has a role that allows this" instead of "is owner."

"What if Maya edits the draft while her writer is still typing?"

"Sections 4 and 7 already cover it: the second save gets a 412, the client files its copy with POST …/revisions, fetches the other version with GET …/draft, and the writer picks. Nobody's words disappear. With two people per draft, 412s stop being rare, and that rate is my early signal that customers want real co-editing."

Unchanged: the read path, the CDN, and the feed (fan-out is keyed by publication_id). The byline comes from posts.author_id, there all along.

Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.