Section 2: The Reader Is the Customer - Requirements (Functional & Non-Functional)

Executive Summary: Section 1 left us with a Stack Overflow-shaped product that has Reddit-style nested comments, read mostly by anonymous visitors from search engines. This section turns that scope into a contract. The functional half splits cleanly into a read side, a write side and an async side. The non-functional half puts a number on every promise: page latency, vote latency, freshness, availability and durability. The key idea is that consistency is set per data type. A vote count may lag by a minute, but a duplicate vote may never happen.

The interviewer looks at the assumptions on the board. "Fine. Now what exactly are we promising, and to whom?"

Start with the "to whom", because it decides most of what follows. Of 50M daily visitors, 40M (80%) never sign in. They arrive from a search engine, read one page, and leave with their answer. The reader in Lagos who searched an error message is the customer. Priya, Daniel and Ana are the supply side: they write the content that makes the page worth landing on. Both groups matter, but they need different promises, so we'll state them separately.

The Functional Contract

Group the requirements by which side of the system they load. That grouping turns into the architecture later.

Read side (300M page views a day):

1. View a question page. The question, its answers sorted by score (ties by age), and the comment threads under each post. The accepted answer is badged but not pinned, as on Stack Overflow since 2021.
2. Browse tag pages and feeds. Lists sorted by hot, new and unanswered.
3. Search. Full-text search over questions and their answers, filterable by tag.

Write side (11.6M writes a day):

4. Ask. A title, a Markdown body and 1 to 5 tags. Priya asks "Why does my Postgres query ignore the index for LIKE '%term%'?", tagged postgresql and indexing.
5. Duplicate suggestions while asking. As Priya types the title, the ask page shows similar existing questions. Every duplicate splits the answers across two pages.
6. Answer. Daniel answers within ten minutes: a B-tree can't serve a leading-wildcard LIKE, but a trigram GIN index can.
7. Comment, and reply to a comment. Ana comments on Daniel's answer, and Daniel replies to Ana's comment. How deep we render threads is a Section 7 question.
8. Vote up or down. At most one vote per person per post, changeable or removable at any time. No voting on your own posts, and downvoting is a privilege earned at 125 reputation.
9. Accept an answer. Only the asker can accept, and only one answer at a time. Priya accepts Daniel's.
10. Edit with history. Others can edit a post wiki-style. Every revision is kept, and two people editing at once must not silently erase each other's work.
11. Flag content. Any signed-in user can flag spam or abuse. A post with 6 spam or rude flags is hidden automatically, pending review.

Async side (seconds behind the write):

12. Reputation. +10 per upvote on a question or answer, −2 per downvote received, +15 for an accepted answer, capped at 200 a day from upvotes.
13. Basic in-app notifications. Priya hears when Daniel answers, Ana when Daniel replies. About 4M a day.
14. Keeping pages and search current. New content reaches the page and search without anyone refreshing.

The interviewer probes the vote requirement: "Why insist a vote is changeable? Simpler if it's final."

You: "Because people misclick, and because a final vote makes the API stateful in the wrong way. If a vote is a state, 'my vote on this post is +1', then sending it twice is harmless. If it's an event, 'add one', every retry double-counts. Changeable votes and safe retries come from the same design, which Section 4 turns into the API."

Quick check before moving on: