Design Quora

Clarify the ask

The interview question is to design Quora, a service built around questions and the answers people write under them.

A reader asks a question. Other readers write answers, and each answer can collect votes from readers who found it helpful.

A question page shows its answers with the strongest answers first. Finding the right page and trusting its order are the heart of the service.

A home feed shows each reader questions and answers matched to the topics the reader follows. Search finds questions and answers by words.

Quality is part of the ask. A service that returns weak answers first fails even if every page loads quickly.

Estimate the scale

The service stores 100,000,000 questions, a stated design figure.

10,000,000 new answers arrive a day. 10,000,000 ÷ 86,400 seconds a day = 116 new answers per second, rounded.

Readers open 300,000,000 question pages a day. 300,000,000 ÷ 86,400 seconds a day = 3,472 page reads per second, rounded.

300,000,000 page reads ÷ 10,000,000 new answers = 30 page reads for every new answer written.

The service is read-dominant. Caching and precomputation will do more work here than write scaling.

Name what is in and out of scope

In scope are questions, answers, and votes. In scope are the question page, the home feed, and search.

In scope is ordering answers by strength. This design orders by a plain score built from votes and freshness.

A learning-based ranker, if one is added later, plugs in at the ordering step as a seam. How such a ranker works inside stays outside this design.

Out of scope are private messages and live chat. The ask is a public record of questions and answers.

Sketch the high-level shape

App servers take the requests. They read and write through a small set of stores, one per kind of record.

One store holds questions and one holds answers. A third holds votes, and vote totals are kept ready on the answer record itself.

A cache holds hot question pages. A page for a famous question is read constantly and changes rarely, which is the ideal shape for a cache.

A search index holds the words of questions and answers. A feed builder prepares home feeds ahead of time for active readers.

Records come first, then feed and votes, then search, then the trade-offs.

State the hard parts honestly

The first hard part is ordering. Votes are a rough signal, and the design must turn them into an order readers trust.

The second hard part is duplication. The same question gets asked many times in different words, and scattered answers help nobody.

The main idea is simple. A vast stored library of questions, a steady stream of new answers, and far more reading than writing.

The data model and API step

A question record holds the question text and points to its answers, and an answer record holds one answer and the name of its writer. Those records and the paths that read and write them are the core of the service.

The data model and API step designs the records first, because every later choice reads or writes them.

A question record holds the question text, the name of the asker, the time it was asked, and its topics. Topics are the subjects a question belongs to, and readers follow topics.

An answer record holds the answer text, the name of its writer, the time it was written, and the record it answers. It also holds its vote total, ready to read.

A vote record holds the answer it votes on, the reader who voted, and the direction of the vote. One reader holds one vote on one answer, and the record enforces that.

The API is plain. Ask a question takes question text and topics, add an answer takes a question and answer text, and read a question page takes a question and returns its answers in order.

The write path for answers

A writer submits an answer. The app server stores the answer record, then adds the answer to the index of its question.

New answers arrive at 116 per second. That is a gentle write rate, and a single well-indexed store handles it without drama.

In this worked example, one stored answer with its metadata takes 1 KB. 10,000,000 answers a day × 1 KB = 10,000 MB of new answer data a day.

10,000 MB a day is 10 GB a day. 10 GB a day × 365 days = 3,650 GB of new answers a year.

3,650 GB ÷ 1,000 GB in a TB = 3.65 TB of new answers a year.

Storage growth is steady and modest. The design spends its effort on reads and ordering, not on surviving the write rate.

The read path for a question page

A reader opens a question page. The app server fetches the question record, then the answers under it, already ordered by score.

Question pages are read at 3,472 per second. Most of those reads land on a small set of famous questions.

A cache holds the finished page for hot questions. The cache entry is dropped when a new answer lands or a vote total changes enough to move the order.

Cold questions skip the cache. Their pages are built from the stores on demand, and the stores are indexed by question so the answers arrive together.

Pagination applies to long answer lists. The first page carries the top answers, and later answers load only when the reader asks.

Duplicates and edits

The same question arrives in many wordings. When two questions mean the same thing, one is marked as a duplicate and points to the other.

Answers gather on the surviving question. Readers land on one strong page instead of five thin ones.

Search helps at asking time. The asking flow suggests existing questions with similar words before the new question is saved.

Writers can edit their answers. An edit updates the record and keeps the vote total, because the votes judged the answer and not one exact wording of it.

Two answers posted at the same moment never clash. Each is its own record under the question, and the ordering step sorts them afterwards.

Where the records break

A vote total on the record can drift from the vote records behind it. A background job recounts totals from the vote records and repairs any drift it finds.

A famous question can collect more answers than one page should carry. Pagination and a firm order keep the page fast, and weak answers sink out of sight.

The main idea stands. Simple records, a gentle write path, and a cached, ordered read path carry the core of the service.

The deep dive on feed and votes

The Quora feed is the ordered list of questions and answers a reader sees, ordered by a score rather than by time alone. The feed is ordered by the votes its answers collect.

The feed is what a reader sees first, and votes are the signal that orders it.

Ranking means ordering items by a score instead of by time alone. Feed ranking applies that ordering to questions and answers.

A reader follows topics and other readers. The feed draws its candidates from what the reader follows.

How a vote is recorded

A vote is a reader's judgement on one answer. An upvote says the answer helped, and a downvote says it did not.

One reader holds one vote on one answer. Casting the other way replaces the old vote, and casting again removes it.

The vote record is stored first. An atomic counter then adjusts the vote total kept on the answer record, up or down by the change.

An atomic counter is a counter that many servers can adjust safely at once. It keeps totals exact under a rush of votes.

Dedupe guards the path. A retried vote request carries the same identity and counts once, so a flaky connection cannot vote twice.

From votes to a score

Each feed candidate gets a score. The score rises with the vote totals of its answers and falls as the item ages.

The score is plain arithmetic on stated signals. Votes and age are the inputs, and no other inputs are named.

A brand new answer has no votes yet. A small starting place in the feed gives new answers a fair chance to earn their first votes.

In this worked example, one feed read sorts 100 candidates. That count is a stated assumption for the example.

3,472 feed reads per second × 100 candidates = 347,200 candidate sorts per second.

That sorting cost is the problem precomputation solves. Precomputation moves the sorting off the read path.

Precompute the feed

Precomputation means building an answer before it is asked for. A background job builds each active reader's feed ahead of time and keeps it ready.

The job rebuilds a feed when its inputs change. A followed topic gains a strong new answer, or a followed writer posts, and the feed is refreshed.

Fan-out on write is the same shape as the news feed design. New content is pushed into ready feeds instead of being gathered at read time.

Rare readers get no precomputed feed. Their feeds are built on read, because building ahead for a reader who may never return wastes the work.

A read then becomes simple. The server fetches the ready feed, or builds a small one, and returns the first page.

Where the feed breaks

Vote spam is the standing attack. Accounts voting in organised rings can lift weak answers, so rate limiting and account checks guard the vote path.

A sudden vote rush can stale a precomputed feed. The rebuild trigger treats a fast-rising answer as urgent and refreshes the affected feeds first.

A precomputed feed can feel a minute old. For a reading service that delay is acceptable, and the question page itself always shows live totals.

The main idea stands. Votes are recorded once and counted atomically, scores order the candidates, and precomputation keeps that order off the read path.

The deep dive on search

Quora search finds questions and answers whose text matches the words a reader types. A search index sits behind that search, and each search travels a short path through it.

Search is how a reader with a specific question finds the page that already answers it.

Good search protects the whole service. Every search that finds an existing answer is a duplicate question that never gets asked.

The design has two halves. One half builds an index of the stored text, and the other half answers searches from that index.

Build the search index

A search index is a list that maps each word to the questions and answers containing it. Looking up a word returns its pages directly, without reading the whole library.

A background job builds the index. It reads each new question and answer, splits the text into words, and adds the record to the list for each of its words.

Common words carry little meaning. The job skips the smallest joining words, which keeps the index smaller and the results sharper.

Edits flow through the same job. An edited answer is indexed again, and its old word entries are replaced.

Estimate the index

In this worked example, the text of one stored question averages 200 bytes. That figure is a stated assumption for the example.

100,000,000 questions × 200 bytes = 20,000,000,000 bytes of question text.

20,000,000,000 bytes ÷ 1,000,000,000 bytes in a GB = 20 GB of question text.

The index itself is a fraction of the text it covers. Answers add far more text than questions, and the index grows with all of it, steadily and predictably.

The index is sharded by word. Each shard holds the lists for its range of words, so no single server holds or serves the whole index.

Answer a search

In this worked example, one read in ten starts as a search. That share is a stated assumption for the example.

300,000,000 page reads a day ÷ 10 = 30,000,000 searches a day.

30,000,000 searches ÷ 86,400 seconds a day = 347 searches per second, rounded.

A search looks up each typed word in the index. The pages holding all the words are gathered, then ordered by the same vote-based strength as the question page.

Popular searches are cached. The same questions are searched for every day, and a cached result page serves them without touching the index.

Search suggestions reuse the trie from the typeahead design. As the reader types, likely question titles are offered, and picking one skips the search entirely.

Where search breaks

A new question is not searchable the moment it is saved. The indexing job reaches it shortly after, and the asking flow says the question is being added.

One index shard can fail. Replicas of the shard serve its words while it recovers, so search narrows instead of dying.

A single very common word can overload its shard. Its list is split and its results are cached hardest, because common words produce the most repeated searches.

The main idea stands. An index built in the background, sharded by word, and fronted by a cache turns a library of 100,000,000 questions into a fast search.

Weigh the trade-offs

Trade-offs in the Quora design are the gains and losses behind its main choices, from ready vote totals on each answer to feeds built before they are read. The main choices are weighed for what they bought and what they cost.

Trade-offs and wrap-up are the last step of the method. Each choice bought something and cost something.

The design as a whole chose reading quality first. Storage and writes were never the danger at this scale, so the effort went to ordering and serving reads.

The scale behind every choice stays fixed. New answers arrive at 116 per second, and question pages are read at 3,472 per second.

Ready totals against true totals

Storing the vote total on the answer record buys fast pages. No read ever counts votes one by one.

The cost is a total that can drift. A recount job repairs drift from the vote records, and the design accepts that housekeeping as the price of fast reads.

Counting on every read would always be exact. At thousands of reads per second it would also be far too slow, and this design refuses that trade.

Precomputed feeds against freshness

Precomputing feeds buys a calm read path. The sorting cost is paid in the background, spread over time, instead of landing on every read.

The cost is a feed that can lag a new answer by a short while. For a reading service the lag is a fair price, and live question pages cover readers who need the newest state.

Building every feed on read would always be fresh. The sorting arithmetic shows why that freshness is unaffordable at full scale.

Delayed search and merged duplicates

Indexing in the background buys a fast write path. The cost is a short delay before new text can be found by search.

Instant indexing would close that delay. It would also slow every question and answer write, most of which are never searched for in their first minutes.

Merging duplicate questions buys one strong page. The cost is judgement calls about sameness, and a merged writer can feel overridden.

Leaving duplicates alone avoids those calls. It scatters answers across thin pages, which quietly harms every future reader, and this design refuses that trade too.

Wrap up the design

Quora stores questions and answers as simple records, with vote totals kept ready on each answer. Question pages are cached and ordered by a plain score built from votes and freshness.

Home feeds are precomputed for active readers. Search runs over an index sharded by word, built by background jobs and fronted by a cache.

The main idea, said once more, is a read-dominant library. The design spends where the readers are, on ordering they can trust and pages that arrive fast.

Quora at a glance