The problem
"Design Quora." People ask questions, others write answers, and readers upvote the answers that helped. Everyone follows topics and people, and gets a feed of answers to read and questions they could answer.
This practice problem reuses the pattern of Design Reddit. Four things are new: a question's answers are ranked by quality rather than votes alone, the feed is built from what each reader follows, an answer keeps being read for years, mostly by visitors from search engines, and the same question must not be asked twice. Park private messages and ads: each is a system of its own.
The numbers
From the interviewer: about 200 million answer pages read a day, and about 1 million new answers written a day. Round a day to 100,000 seconds (86,400 really); busy hours run about 5× the average.
- Page reads: 200 million ÷ 100,000 = 2,000 a second on average (about 2,300 with 86,400), so about 10,000 a second at busy hours.
- New answers: 1 million a day, about 10 a second. Each answer is read about 200 times: reading is the busy path.
- Storage: say an answer is about 2 KB of text: 2 GB a day, about 730 GB a year. The reads are the problem, not the storage.
Ranking answers: votes and credibility
Votes alone reward what is popular, not what is right: a famous comedian's one-line joke can outvote a teacher's careful plan. So each writer also has a credibility per topic, worked out in the background from the upvotes their past answers in that topic received, from 0.1 for a newcomer up to 1. A toy score multiplies the two:
answer writer upvotes credibility score
a2 teacher 150 0.9 135
a4 engineer 200 0.5 100
a1 comedian 400 0.1 40
a3 core developer 30 1.0 30
The teacher's answer leads. Ranking by upvotes alone would put the joke first; ranking by credibility alone would put the core developer's hour-old answer first, before readers have said whether it helps. Weighted, that answer climbs as votes arrive: at 140 upvotes it would lead. Starting newcomers at 0.1 rather than 0 lets a great first answer rise. Credibility is a row per (writer, topic), and the ranker recomputes scores as votes come in, as Reddit's ranker does.
The feed: ready lists per topic
Ana follows 20 topics and 50 people. A topic like Python has 5 million followers and gets about 2,000 new answers a day. Pushing each new answer into every follower's feed, the way Twitter pushes tweets, would cost 5 million writes per answer, 10 billion a day for Python alone: the celebrity problem, for every big topic. Ranking all recent answers of her topics on every open puts heavy work on the busy path.
Instead, each topic keeps ready lists in the cache, its best new answers and its open questions, rebuilt by the ranker like a community's hot list in Reddit. Opening the feed reads her 20 topics' lists, takes the first 25 of each (500 candidates) and ranks them for her. Say 100,000 active topics × 2 lists × 1,000 ids × 8 bytes: about 1.6 GB. The people she follows usually have few followers, so their new answers can be pushed into her own list; a writer with millions of followers is merged at read time, like a topic.
Old answers: cached pages and a CDN
An answer from 2016 is still read every day, and most readers aren't signed in: they arrive from a search engine. Say 80% of reads are signed out. A signed-out page is the same for every reader, so render it once and let a CDN keep the whole page near the readers: 8,000 of the 10,000 reads a second at busy hours never reach our servers.
Signed-in pages differ per reader (their own upvotes and follows), so the servers build them, from popular answer pages kept in the cache: say the 1 million most-read pages at about 50 KB each, 50 GB. When an answer is edited, its cached pages are purged. Don't treat old as cold: moving old answers to slow storage hurts the long tail that search engines keep sending readers to.
Duplicate questions: search by meaning
Ana starts typing "Best way to learn Python". "How to learn Python?" already has 120 answers. A second page would split the answers: writers answer twice, and readers from search find half. So, before she posts, the system looks up the questions closest in meaning and offers them; she follows the existing one instead.
Counting shared words fails: "Best way to learn Java" shares 4 of her words (best, way, to, learn), "How to learn Python?" only 3. Turning each title into an embedding, numbers that place text by meaning as in the RAG lesson, puts the Python question first. A keyword index, as in Search Engine, can add candidates. Duplicates that slip through are merged later: one question becomes a redirect to the other, so old links keep working.
Same pattern as Reddit
Votes are rows keyed by (user, answer), the score is kept ready on the answer, and the API server saves the vote row and puts the change on a vote queue for the ranker. Ranked lists are built in the background and read from memory, never sorted on every view.
POST /questions {: "Best way to learn Python"}
GET /questions/similar?title=… → the closest questions
POST /answers/a2/vote {: 1}
GET /feed?cursor=…
Summary
- Scope: ranked answers, a feed from what you follow, no duplicates, pages read for years.
- Numbers: about 10,000 page reads a second at busy hours, 200 per answer written.
- Answers: upvotes × the writer's credibility in the topic, recomputed by the ranker.
- Feed: each topic's ready lists, merged when the feed opens.
- Scale: a CDN for signed-out pages; popular pages in the cache, purged on edit.
- Duplicates: similar questions by meaning, offered before posting.