Design a question-and-answer site

People ask questions, others answer, everyone votes, and the best answer should rise to the top, for the person who asked and for the millions who arrive from a search engine years later. Most traffic is anonymous reading; the hard parts are ranking answers fairly, spotting duplicate questions, and keeping a community of writers motivated.

1. The prompt

"Design a Q&A site: users post questions, write answers, vote, and follow topics. Show the best answers first, and help people find existing answers before they ask again."

What makes it hard:

• Ranking with little data. An answer with 3 upvotes and 0 downvotes isn't obviously better than one with 90 and 10.
• Duplicates. The same question is asked in a hundred wordings; answers get spread thin.
• Reads dwarf writes, and most readers arrive from search engines, not the home page.

2. Frame the problem

3. What it must do

1. A user can ask a question and is shown similar existing questions before posting.
2. A user can answer and vote; each question shows its answers best first.
3. A user sees a feed of questions from topics and people they follow, and can search everything.

Not now: private messaging, paid answers, live sessions, AI-written answers (a follow-up in section 10).

4. How well it must do it

5. Numbers that change the design

6. The nouns

• User (with reputation), Question, Answer, Comment.
• Vote: one per user per post.
• Topic and Follow.
• Duplicate link: question A is a duplicate of question B.

questions   question_id, author_id, title, body, topic_ids[], score, answer_count, accepted_answer_id, duplicate_of, created_at
answers     answer_id, question_id (index), author_id, body, up, down, rank_score, created_at
votes       user_id, post_id, value (+1 | -1), created_at     PRIMARY KEY (user_id, post_id)
follows     user_id, target_type (topic | user), target_id
reputation  user_id, points                                    (derived from votes, recomputable)

7. The contract

POST /v1/questions             {title, body, topics}   Idempotency-Key: …   → {question_id, url}
GET  /v1/questions/similar?title=…                     → [{question_id, title, answer_count}]   (while typing)
GET  /v1/questions/{id}?answers_sort=best&cursor=…   → {question, answers: [...], next_cursor}
POST /v1/questions/{id}/answers {body}                 → {answer_id}
PUT  /v1/posts/{id}/vote       {value: 1 | -1 | 0}     → {up, down}       (PUT: repeating it is harmless)
GET  /v1/feed?cursor=…                                 → [{question summary}]
GET  /v1/search?q=…&cursor=…                          → [{question summary, matched answer snippet}]

8. First working version

Stateless web servers, one relational database with replicas, Redis for caching, a CDN, and blob storage for images.

8.1 Asking (with duplicate suggestions)

As the title is typed, the client asks for similar questions (first version: full-text search on titles). On submit, one insert, then an event so search, feeds and notifications update asynchronously.

8.2 Reading a question

A signed-out visitor gets the whole rendered page from the CDN or the page cache. Signed-in users get the same cached page plus a small personal layer (their votes, follow state) fetched separately.

8.3 Voting

Upsert the vote row keyed by (user, post): repeating a vote changes nothing, and switching from up to down is a single update. Counts on the answer are updated from that change.

9. Make it hold up

9.1 Ranking answers fairly fair ranking

Compute rank_score when votes change (asynchronously) and store it, so reading a question is a simple indexed sort.

9.2 Finding duplicate questions suggestions under 300 ms

• Keyword search on titles catches same-word duplicates but misses "How do I reverse a list?" vs "Flip the order of an array".
• Embeddings (Module 29): turn each question title into a vector; nearby vectors mean similar meaning. A nearest-neighbour index returns candidates as the user types.
• Combine both (hybrid search), re-rank with a classifier trained on questions the community already merged (Quora published such a dataset), and show the top five.
• When the community closes a question as a duplicate, redirect it to the original and fold its answers in, so search engines and links lead to one complete page.

9.3 Votes on a hot answer votes counted once

• The votes table, with its primary key on (user, post), is the truth: uniqueness comes from the database.
• Counters are derived: a vote event goes on a queue; a worker batches increments per post every second or two (Module 18) and recomputes rank_score. A viral answer's thousand votes a minute become a few dozen writes.
• Reputation is derived the same way, and can be recomputed from the votes table after fraud is removed.

9.4 The personalised feed reads keep working

Unlike a social feed, questions stay relevant for years and topics have millions of followers, so fan-out on write is wasteful. Build the feed on read: take recent and top questions from the user's followed topics (each topic's list precomputed and cached), merge, rank by a model (topic affinity, answer quality, freshness), and cache the result for a few minutes. Design D06 explains the push vs pull trade-off.

9.5 Caching pages that change question pages under 300 ms

9.6 Spam, abuse and vote fraud security

New posts from new accounts go through a spam classifier and rate limits; low-confidence posts wait in a review queue. Vote fraud (sock-puppet accounts, voting rings) is detected offline by looking for accounts that vote mostly for one person, then those votes are reversed and reputation recomputed. Users unlock moderation abilities as reputation grows, which spreads the review work.

9.7 The whole design after the deep dives

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Slightly stale counts and pages for huge cache hit rates.
• A confidence-based ranking instead of simple vote sums.
• Feeds built on read, because questions live for years.
• One database first; derived stores for search, feeds and counters.

What we'd watch: CDN and page-cache hit rates · question page p95 · duplicate-suggestion click-through · vote queue lag · spam rate · answers per question.

At 10×: separate the vote store, shard questions by ID, more CDN capacity.

Common mistakes:

• Sorting answers by net votes.
• Updating a counter row in the request for every vote.
• Fan-out on write to millions of topic followers.
• Sharding a dataset that fits on one machine.
• Treating every page view as a personalised request.

13. Try it, check yourself, read more

Answer-ranking lab. Five answers to one question, with their upvotes and downvotes. Switch the ranking and watch the order change. Then give the newest answer a few more upvotes.

Wilson lower bound at 95% confidence: the lowest share of upvotes that's still consistent with the votes seen so far.