Design a Q&A site (Stack Overflow / Quora)

Stack Overflow is a well-known example of a top-traffic site running on a small number of web servers and a primary SQL Server with replicas. The lesson for the interview: at a few thousand page views per second and under 1 TB of data, you do not need sharding or microservices. What you need is a fast read path. Layers: (1) CDN caching of full pages for anonymous users, who are the large majority; a TTL of ~60 s is acceptable because a new answer appearing a minute late is fine. (2) Redis caches rendered page fragments per post (question block, each answer block), so a new answer only invalidates its own fragment and the answer list. (3) Read replicas take the remaining queries; writes go to the primary. (4) Store rendered HTML next to Markdown so reads never pay for Markdown parsing and syntax highlighting. (5) Counters like view_count are batched in Redis. With this, more than 95% of requests never touch the database. Logged-in users get the same cached fragments plus a small personalised part (their votes, their reputation), assembled at render time.

Reputation is the platform's currency: it unlocks privileges (comment at 50, edit at 2,000 on Stack Overflow) so it must be correct and explainable. Model it as an append-only ledger of reputation_events, each with a reason and a link to the vote or accept that caused it. The user's reputation is the sum, cached in the users table and updated in the same transaction as the vote. Benefits: when a vote is removed, a post is deleted, or fraud is found, we add reversing events rather than editing totals, so history stays auditable and the user can see 'why my rep changed'. Rules like the daily cap (200 reputation per day from upvotes) are applied when events are generated. Because write volume is small (tens per second), a single relational transaction covering vote + score + reputation is simple and strongly consistent; no queue or saga is needed. That is a good point to make: choose the simple consistent design when the numbers allow it, and explain at what scale you would move score updates to an async pipeline.

Two search needs: users searching for answers, and the ask flow suggesting duplicates before a question is posted. Both are served from an Elasticsearch index fed by change data capture (Debezium reading the database log into Kafka), so the database stays the source of truth and indexing never blocks writes. Keyword search uses BM25 over title (boosted), body and tags, with filters on tags and sort by votes or recency, and code-aware tokenisation (do not split 'std::vector' or 'C#'). Duplicates are often phrased differently ('reverse a list in python' vs 'how to invert a python list order'), which keyword search misses. So we also store an embedding of each question's title and body and run approximate nearest neighbour (HNSW) search, then combine keyword and vector results with reciprocal rank fusion. A small re-ranker or rules boost questions with accepted answers. This hybrid is the same pattern as RAG retrieval and is a natural AI-era extension: an LLM can draft a summary answer from the top retrieved posts, with links, but must cite sources and never replace community answers silently.

A Q&A site lives or dies by content quality. Community moderation is privilege-based: users above thresholds can vote to close, mark as duplicate, or reopen; 5 close votes (or one moderator) close a question. Close votes are stored as rows with a review queue, and a closed duplicate links to the canonical question so search engines and users land on the best answer. Review queues (first posts, late answers, low quality) are just filtered lists of posts with flags, assigned to reviewers. Automated defences: rate limits for new users (one question per 90 minutes is a known Stack Overflow style rule), spam classifiers on new posts, link and phone number detection, and blocking of posts from users with many deleted questions. Detected voting rings trigger reputation reversal. All moderation actions are logged in a post history table so decisions can be audited and undone. AI-generated answers are a current problem; platforms set policies and use detection plus human review rather than trusting a classifier alone.

At this scale (thousands of reads/s, tens of writes/s, < 1 TB), a well-indexed relational database with replicas and caching is simpler, cheaper and strongly consistent. Microservices and NoSQL add operational cost without solving a real problem. Say when you would change: e.g. Quora-scale personalised feeds and billions of rows of interactions.

With ~50 votes/s, updating score and reputation in one transaction is fine and gives exact numbers. A viral site with thousands of votes per second on one post would need async aggregation (like Reddit), accepting short lags.

BM25 is cheap, explainable and great for exact error messages and code tokens. Embeddings find paraphrased duplicates but cost model calls and vector storage. Use both and fuse results.

A question trending on social media gets many new answers and votes per minute, each invalidating its page. Use fragment-level invalidation and short TTLs on the full page; coalesce invalidations to at most once every few seconds.

Single primary will eventually limit writes. Move high-rate, low-value writes (views, impressions) to Redis/Kafka batches first; that removes most write load before any sharding is needed.

Automatic failover to a synchronous replica in seconds to a minute. During failover the site switches to read-only mode: pages still load from caches and replicas; asking and voting show a 'temporarily read-only' message.

Question pages are unaffected. Site search falls back to a simple title search on the database or shows an error; the ask flow skips duplicate suggestions. CDC events wait in Kafka and are replayed when search recovers.

Raise rate limits for new accounts, require captcha or reputation to post links, and let high-rep users' spam flags delete posts quickly (e.g. 6 spam flags auto-delete).