Designing a Q&A Forum (Quora / StackOverflow)

Difficulty: Intermediate Prerequisites:Caching, Database Indexing, and Fan-Out

TL;DR

A Q&A forum lets users post questions, write answers, and vote on both. Reads dominate writes 100:1, and most visitors arrive cold from a search engine to read one question and its top answers. The hard parts: serving that read volume cheaply, ranking answers so the best one lands first, and full-text search over 10M questions.

The shape of the answer: Postgres as the source of truth, Redis in front of the read path, Elasticsearch beside it for search, and rankings computed asynchronously rather than per request.

Understanding the Problem

A Q&A forum lets users post questions, write answers, and vote on both. Readers vastly outnumber writers — most traffic is people reading a question and its top answers, often arriving from a search engine. The hard parts: serving reads cheaply at scale (100:1 read-to-write ratio), ranking answers so the best one appears first, and providing full-text search across millions of questions.

The read-heavy skew is the single most important fact about this system. It means a cache is not an optimisation you add later — it is load-bearing from day one. It also means the write path can afford to be slower and do more work (recompute rankings, fan out to a search index) because writes are 1% of traffic.

Naive First Cut

flowchart LR
    USER["User"]:::client
    API["Monolith API"]:::service
    DB[("Single SQL DB")]:::data

    USER --> API
    API --> DB

    classDef client fill:#4c3a5e,stroke:#818cf8,color:#e2e8f0
    classDef service fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0
    classDef data fill:#3b3520,stroke:#fbbf24,color:#e2e8f0

Why this breaks:

• Hot questions (viral content) get 100K reads/sec — single DB can’t handle the load
• Full-text search with LIKE '%keyword%' does a full table scan, no relevance ranking
• Computing “top answers” on every read (sort by votes) is expensive when there are 500 answers
• Feed generation for 10M users requires scanning all followed topics per request
• No caching — same popular question page is recomputed on every request

The rest of the doc evolves this into a design that survives a front-page traffic spike.

Prior Art We’re Drawing From

• Stack Overflow — famously runs on a remarkably small server footprint: a handful of SQL Server boxes plus aggressive caching, because an immutable-ish question page is close to a perfect cache candidate. Proof that read-heavy Q&A is a caching problem before it is a sharding problem. (Stack Overflow architecture)
• Quora — separates the write store from the read/serving path and computes ranking and feed material asynchronously, keeping page loads free of ranking work. (Quora Engineering)
• Reddit — its comment ranking uses time-decayed and confidence-based scoring (Wilson score for “best”) rather than raw vote counts, which is exactly the ranking problem in Deep Dive 2. (Reddit ranking algorithms)

Functional Requirements

Core (top 3)

1. Post and read Q&A — users post questions, others write answers, anyone can read
2. Vote on answers — upvote/downvote; answers ranked by score
3. Search questions — full-text search across all questions by keyword and tags

Below the Line

• User profiles, comments on answers, tag system, personalized feed, notifications, moderation tools

Non-Functional Requirements

• Read latency — <100ms for question page loads (including top answers)
• Scale — 10M questions, 50M answers, 100:1 read-to-write ratio
• Search — full-text results in <200ms with relevance ranking
• Availability — 99.9%; read path must stay up even if write path degrades

Below the Line

• Strong consistency on vote counts (a vote appearing seconds late is fine)
• Real-time updates to an open page
• Multi-region active-active writes

Scale Estimation (Back-of-Envelope)

• Corpus: 10M questions, 50M answers (~5 answers/question)
• Read QPS: ~50K question-page reads/sec average; a front-page item can add 100K/sec on one key
• Write QPS: ~500/sec combined (new questions, answers, votes) — 100:1 skew
• Storage: 50M answers × ~2KB ≈ 100GB of text, plus indexes. Fits comfortably in one Postgres instance with read replicas — this system does not need sharding, which is the main thing to say out loud.
• Search index: 10M docs × ~1KB indexed fields ≈ 10GB, a small Elasticsearch cluster
• Cache working set: the hot 1% of questions ≈ 100K pages × 50KB ≈ 5GB in Redis

The numbers matter because they tell you what not to build. 100GB and 500 writes/sec is a single-primary Postgres workload. Proposing a sharded multi-region datastore here is over-engineering, and a good interviewer will push back on it.

Core Entities

• Question — title, body, tags, author, created_at, view_count
• Answer — body, author, question reference, vote_score, created_at
• Vote — user, target (answer/question), direction (up/down)
• Tag — name, question count (for discovery)

API / System Interface

POST /v1/questions
  Body: { title, body, tags: ["system-design", "caching"] }
  Response: { questionId, slug }

POST /v1/questions/{questionId}/answers
  Body: { body }
  Response: { answerId }

GET /v1/search?q=distributed+caching&tags=system-design&page=1
  Response: { results: [{ questionId, title, score, answerCount }], total }

High-Level Design

FR1: Post and Read Q&A

The Question Service writes to Postgres. For reads, a Redis cache sits in front — popular question pages are cached with a short TTL.

flowchart LR
    USER["User"]:::client
    API["Q&A Service"]:::service
    CACHE[("Redis<br/>page cache")]:::data
    DB[("Postgres")]:::data

    USER -->|"1. GET question page"| API
    API -->|"2. Lookup cached page"| CACHE
    CACHE -.->|miss| DB

    classDef client fill:#4c3a5e,stroke:#818cf8,color:#e2e8f0
    classDef service fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0
    classDef data fill:#3b3520,stroke:#fbbf24,color:#e2e8f0

FR2: Vote on Answers

Votes update the answer’s score. The write goes to Postgres; the cached question page is invalidated so the next read fetches fresh rankings.

flowchart LR
    USER["User"]:::client
    API["Q&A Service"]:::service
    DB[("Postgres")]:::data
    CACHE[("Redis")]:::data

    USER -->|"1. POST upvote or downvote"| API
    API -->|"2. Write vote to DB"| DB
    API -->|"3. Invalidate page cache"| CACHE

    classDef client fill:#4c3a5e,stroke:#818cf8,color:#e2e8f0
    classDef service fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0
    classDef data fill:#3b3520,stroke:#fbbf24,color:#e2e8f0

FR3: Search Questions

An Elasticsearch index stores questions with full-text fields. Writes to Postgres are synced to ES via async pipeline.

flowchart LR
    USER["User"]:::client
    API["Q&A Service"]:::service
    ES[("Elasticsearch")]:::data
    DB[("Postgres")]:::data
    KAFKA["Kafka"]:::async

    USER -->|"1. Search questions"| API
    API -->|"2. Full-text query"| ES
    DB -->|"3. Change events"| KAFKA
    KAFKA -->|"4. Sync to search index"| ES

    classDef client fill:#4c3a5e,stroke:#818cf8,color:#e2e8f0
    classDef service fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0
    classDef data fill:#3b3520,stroke:#fbbf24,color:#e2e8f0
    classDef async fill:#3a2a4c,stroke:#c084fc,color:#e2e8f0

Technology Choices

Why Postgres instead of sharding? 10M questions × 50M answers × ~2KB ≈ 100GB of text. That fits comfortably in one Postgres instance with read replicas. Stack Overflow runs on a similar footprint. Sharding adds complexity that this read-heavy, moderate-write system doesn’t need.

Data Modeling

Postgres (Primary DB — questions, answers, votes):

CREATE TABLE questions (
    question_id UUID PRIMARY KEY,
    author_id UUID NOT NULL,
    title VARCHAR(300) NOT NULL,
    body TEXT NOT NULL,
    tags VARCHAR(50)[] NOT NULL,
    view_count INTEGER DEFAULT 0,
    vote_score INTEGER DEFAULT 0,
    answer_count INTEGER DEFAULT 0,
    accepted_answer_id UUID,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL
);
CREATE INDEX idx_questions_tags ON questions USING GIN(tags);
CREATE INDEX idx_questions_score ON questions(vote_score DESC);

CREATE TABLE answers (
    answer_id UUID PRIMARY KEY,
    question_id UUID NOT NULL REFERENCES questions(question_id),
    author_id UUID NOT NULL,
    body TEXT NOT NULL,
    vote_score INTEGER DEFAULT 0,
    is_accepted BOOLEAN DEFAULT false,
    created_at TIMESTAMP NOT NULL
);
CREATE INDEX idx_answers_question ON answers(question_id, vote_score DESC);

CREATE TABLE votes (
    user_id UUID NOT NULL,
    target_id UUID NOT NULL,  -- question_id or answer_id
    target_type VARCHAR(10) NOT NULL,  -- QUESTION or ANSWER
    direction SMALLINT NOT NULL,  -- +1 or -1
    created_at TIMESTAMP NOT NULL,
    PRIMARY KEY (user_id, target_id)
);

Redis (Cache — hot question pages):

Key: "question:{questionId}" → Hash { title, body, vote_score, answer_count, accepted_answer_id }
Key: "answers:{questionId}:top" → List of top-voted answer JSON objects
TTL: 5 minutes (invalidated on new answer or vote)

Elasticsearch (Search Index — full-text + tag filtering):

Index: questions
  Fields: title (text), body (text), tags (keyword[]), vote_score (integer), 
          answer_count (integer), created_at (date), author_name (keyword)
  Analyzer: english with stemming + synonyms

Access Patterns:

How Vote Score Updates Propagate:

1. User upvotes an answer → INSERT INTO votes (user_id, target_id, 'ANSWER', +1) — unique constraint prevents double-voting
2. UPDATE answers SET vote_score = vote_score + 1 WHERE answer_id = ? — atomic increment
3. Publish VOTE_CAST event to Kafka → cache invalidation worker DELetes question:{qId} and answers:{qId}:top from Redis
4. Elasticsearch is updated async (Kafka consumer) — search results reflect new score within seconds
5. Next page load rebuilds cache from Postgres (read-through pattern)

Deep Dives

Deep Dive 1: Handling viral questions (thundering herd)

Bad: A question goes viral — 100K users hit the page simultaneously. Cache TTL expires, all 100K requests hit the DB at once (thundering herd). DB overloads and the whole site slows down.

Good: Use a cache-aside pattern with a short TTL (30s). On cache miss, only one request fetches from DB (using a distributed lock or single-flight pattern). All other concurrent requests wait and receive the cached result once the first one completes.

Great: For known hot content (trending questions, front-page posts), use a “cache warming” strategy. A background job identifies trending questions (by view velocity) and proactively refreshes their cache before TTL expiry. This eliminates cache misses entirely for the hottest content. Combined with read replicas on Postgres for the long-tail of unpopular questions, the primary DB only handles writes.

Deep Dive 2: Answer ranking that rewards quality

Bad: Sort by raw vote count. Old answers accumulate votes over time and always stay on top, even when a newer, better answer exists.

Good: Use a time-decayed scoring formula: score = votes / (hours_since_posted + 2)^gravity. Newer answers with fewer votes can outrank older answers with more votes. This encourages fresh contributions.

Great: Combine vote score with engagement signals: answer acceptance (by the question author), view-time (do readers scroll past it or stop?), and author reputation. Weight these into a composite ranking score. Compute rankings asynchronously (not on every page load) and cache the sorted result. Re-rank every few minutes or on significant vote changes (>5 new votes). This keeps page loads fast while providing meaningful rankings.

Deep Dive 3: Full-text search with relevance

Bad: SQL LIKE '%distributed caching%' — no index can help, scans all 10M rows, returns results without relevance ranking.

Good: Elasticsearch index with standard BM25 scoring. Questions are indexed by title, body, and tags. Search returns results ranked by text relevance. Sync from Postgres to ES via Kafka (CDC pipeline) with <10s lag.

Great: Boost search relevance with engagement signals. Weight title matches higher than body matches. Boost questions with more views, votes, and accepted answers. Add tag-based filtering (faceted search). For “unanswered” queries, filter to questions with zero accepted answers — useful for contributors looking to help. Combined with search-as-you-type (prefix completion on the title field), users find answers before even finishing their question.

Design Self-Audit

Final Architecture

flowchart LR
    USER["User"]:::client
    CDN["CDN"]:::edge
    API["Q&A Service"]:::service
    CACHE[("Redis<br/>page cache")]:::data
    DB[("Postgres<br/>primary")]:::data
    REPLICA[("Read Replicas")]:::data
    KAFKA["Kafka<br/>change events"]:::async
    ES[("Elasticsearch")]:::data
    RANK["Ranking Worker"]:::async

    USER -->|"Read question page"| CDN
    CDN -->|"Forward on miss"| API
    API -->|"Check page cache"| CACHE
    CACHE -.->|"miss"| REPLICA
    USER -->|"Post or vote"| API
    API -->|"Write"| DB
    DB -->|"Replicate"| REPLICA
    DB -->|"CDC stream"| KAFKA
    KAFKA -->|"Sync index"| ES
    KAFKA -->|"Recompute scores"| RANK
    RANK -->|"Write sorted rankings"| CACHE
    USER -->|"Search"| API
    API -->|"Full-text query"| ES

    classDef client fill:#4c3a5e,stroke:#818cf8,color:#e2e8f0
    classDef edge fill:#1e3a5f,stroke:#60a5fa,color:#e2e8f0
    classDef service fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0
    classDef data fill:#3b3520,stroke:#fbbf24,color:#e2e8f0
    classDef async fill:#3b1f5e,stroke:#c084fc,color:#e2e8f0

How it works end-to-end (read path — 99% of traffic):

1. User requests a question page — usually arriving from a search engine, so the request is cold for that user but hot for the system
2. CDN serves anonymous traffic — logged-out page views are identical for everyone, so they can be cached at the edge outright
3. Redis page cache — on CDN miss, the assembled page (question + ranked answers) is looked up by question ID
4. Read replicas absorb misses — a cache miss reads from a replica, never the primary, so read traffic can never starve writes

How it works end-to-end (write path — 1% of traffic):

1. Writes go to the Postgres primary — questions, answers, and votes, with a unique constraint on votes preventing double-counting
2. CDC stream publishes changes to Kafka — one change feed, two consumers, so neither indexing nor ranking sits in the user’s request
3. Elasticsearch stays in sync — the indexer consumes the stream and updates the search index within seconds
4. Ranking Worker recomputes answer order — time-decayed scores are computed off the request path and written back to Redis as a pre-sorted list, so page loads never sort 500 answers

Key Technologies

What’s Expected at Each Level

🎯 Key Takeaways

• A 100:1 read skew makes the cache load-bearing, not an optimisation — design the read path first
• Don’t shard this system. 100GB and 500 writes/sec is one Postgres primary plus read replicas; proposing shards is the classic over-engineering trap here
• Rank asynchronously, serve pre-sorted. Sorting 500 answers per page load is the mistake; compute scores on a worker and cache the ordering
• Raw vote counts are a bad ranking. Time decay lets fresh, better answers surface past entrenched old ones
• Search is a separate failure domain — Elasticsearch going down should degrade search, not take down reading
• Invalidate on answer changes, expire votes by TTL — invalidating on every vote destroys the cache exactly when you need it most

Related Designs

• Search Autocomplete - prefix search for the search-as-you-type path
• Twitter Feed - fan-out and feed generation for followed topics
• News Aggregator - time-decayed ranking of user-submitted content
• Rate Limiter - protecting the write path from spam and vote abuse

Related Concepts

Understand the building blocks used in this design:

• Caching → — the load-bearing component for a 100:1 read-to-write ratio
• Database Replication → — read replicas absorb cache misses without touching the primary
• Database Indexing → — makes question and answer lookups fast in Postgres
• CDN → — serves identical anonymous question pages from the edge
• Batch vs Stream → — why ranking is recomputed off the request path
• Fan-Out → — the pattern behind feed generation for followed topics