Section 2: Promises You Can Measure - Requirements (Functional & Non-Functional)
Executive Summary: This section converts Section 1's assumptions into a contract. Seven functional requirements say what the comments system does, from posting a comment to guaranteeing that your friends' comments reach you inside a five-million-viewer stream. The non-functional requirements put numbers on how well it does it: a two-lane latency promise (p99 2 s, or 4 s for the broadcast lane of large streams), 99.95% delivery availability, zero loss of acknowledged comments, and delivery to screens that is deliberately at-most-once. Every number here is an obligation that later sections must meet.
The clarifications are done, and the interviewer asks the obvious next question: "So what exactly are we committing to?" "Comments should feel real-time" is an adjective. "A friend's comment reaches your screen within 2 seconds at p99" is a promise. A test can check it and an alert can page on it. So you write requirements in that second form.
The Functional Contract: Seven Verbs
| # | Requirement | Why it is on the list |
|---|---|---|
| FR1 | Post a comment to a live video | The only write path |
| FR2 | See new comments in near real time | The product itself |
| FR3 | On joining, see the last 50 comments | An empty feed reads as a dead stream |
| FR4 | Scroll back to older comments | Catching up after a distraction |
| FR5 | On replay, see comments at their video moment | Comments are reactions to that moment |
| FR6 | Authors delete their own comments. Broadcasters and moderators delete, block users, set slow mode, followers-only and blocked words, and pin a comment | The people in the room need control over it |
| FR7 | Your own and your friends' comments always appear for you, even in the largest stream (exact scope below) | What makes a crowd feel personal |
FR7 needs a second look, and the interviewer checks it straight away.
Interviewer: "FR2 and FR7 together sound like 'everyone sees everything.'"
You: "They don't say that, and I'm keeping them apart on purpose. FR2 promises a live feed. It doesn't promise every comment. When Aria Vance has five million people on v_8812, nobody can read all of it, so the system chooses what each viewer sees. FR7 sets the floor under that choice. When Maya posts 'Play the acoustic version!!' from São Paulo, she sees it on her screen straight away, and so does her friend Tomás in Lisbon. Most of the other five million never see it, and that's by design."
Key Insight: FR7 forces the design to split delivery in two: a shared feed that everyone receives, plus a small personal one per viewer. Write it down now. Sections 7 and 8 depend on it.
State FR7's scope just as precisely. It holds in normal operation and through any single component failure. Exactly one declared overload mode relaxes it: Section 9's 10× goal burst, when only a sample of comments can enter the live feed and a friend's comment may miss it. That mode is reported, never silent, and the fix that would close it (sending Gateways small id-and-author stubs to match against friends) is already named.
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