Section 2: Writing the Contract - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's assumptions into a contract with two signatories: the writer, who needs an editor that never loses a word, and the reader, who needs a page that appears instantly. Functional requirements split into P0, P1 and out of scope, each exclusion with a reason. Non-functional requirements are numbers: article TTFB p95 ≤ 100 ms from the CDN, autosave ack p95 ≤ 300 ms, every edit at every edge within 60 s p99, 99.99% availability for reading but 99.9% for writing. A per-data-type consistency table closes it. The lesson: the two halves of this product want opposite guarantees.
The assumptions are on the whiteboard. The interviewer nods at them and asks the question that turns a conversation into a design: "Fine. So what, exactly, are we promising?"
This is where adjectives die. "The editor should be reliable" cannot be tested; "an acknowledged autosave is never lost" can.
The Functional Contract
Every requirement belongs to one of the two populations Section 1 separated: 500K daily writers in the editor, and 25M daily readers on article pages.
P0: the product does not exist without these
- Personal publication. Every writer gets one, with a unique handle. Maya's is @maya.chen, titled "Boring Infrastructure".
- Drafts with autosave, saved continuously without pressing anything. Maya drafts "Postgres Is Enough for Your Startup" over three evenings on her laptop and her phone.
- Publish, edit a published post, unpublish. Editing a live post must not show readers a half-edited version.
- Read a post by URL, anonymously, as server-rendered HTML that search engines can crawl. Most readers arrive signed out, from search or a shared link.
- Publication page listing a publication's posts, newest first.
- Follow and unfollow a publication, and a Following feed of new posts from what you follow.
- Claps, capped at 50 per user per post (Medium's rule). Daniel, reading in Berlin, claps the full 50 and follows @maya.chen.
- Image upload inside the editor. Maya's post carries 4.
P1: valuable, but the core stands without them
- Responses (basic comments).
- Keyword search.
- Revision history and restore: restore copies an old revision into the draft; it never touches what is live.
- Scheduled publish.
Out of scope, with reasons (all six return in Section 11's Follow-up Feature Evolution)
| Excluded | Reason it can wait |
|---|---|
| Recommendations / ranked home feed | A separate ranking system; the Following feed is the requirement |
| Paywall and metering | Free product today; paywalls change how HTML is cached |
| Team publications | Single author per post today; leave a membership table so roles slot in |
| Custom domains | Routing and TLS work with no effect on the core data model |
| Real-time co-editing | One person per draft removes merge machinery |
| Email newsletters | An extra consumer of the publish event, not a new core path |
Interviewer: "Why is revision history only P1? Writers love it."
Candidate: "The feature is P1; the data isn't. Publishing creates an immutable revision anyway, and the editor takes periodic checkpoints. Only the browse-and-restore screens wait."
Quick check before moving on:
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