Design a Community Forum with Upvotes

Problem statement

Design a community forum where users create threads, reply in nested discussions, upvote or downvote content, browse ranked listings (hot, top, new), organize content into categories and tags, and earn reputation points from community approval. The brief scopes this as a single-domain or bounded-scope forum — closer to a specialized Discourse community than to Reddit's multi-subreddit planet — but the engineering problems are the same class, only the constants differ.

A forum looks like a CRUD app until you count the writes. Every visible number on the page — score, reply count, view count, reputation — is a counter that thousands of concurrent voters want to mutate at once. The thread with 40,000 votes in one hour is the same row everyone is updating. That hot-counter contention, not page rendering, is what separates a forum from a blog.

Why this problem is distinctive

1. Writes are small, idempotent-ish, and brutally concentrated. A vote is a 3-field write, but 80% of votes land on 5% of posts. Naive row locking serializes the whole community behind one hot row.
2. Reads demand ranked, fresh listings. 'Hot' is a function of votes and time, so every passing second invalidates the ordering. You cannot simply cache it forever, and you cannot recompute it per request.
3. Threads are trees. Replies nest, subtrees collapse, and the render path must fetch a bounded slice of a potentially 10,000-node tree without loading all of it.
4. Trust is adversarial. Votes, accounts, and reputation are all economically valuable to spammers, brigades, and astroturfers. Moderation is an architecture requirement, not a policy page.

Public operating baseline

Public evidence shows the category is real and large. Reddit reported 91.2M daily active users in its Q2 2024 shareholder letter, and its engineering team has publicly described migrating post voting to Redis to absorb vote volume. Hacker News famously serves its front page from a very small number of servers using a gravity-based ranking formula. Stack Overflow publicly reports tens of millions of questions and built its reputation economy on SQL Server with asynchronous denormalization. Discourse, the open-source forum used by thousands of communities, runs on PostgreSQL plus Redis with a trust-level system. These are cited public signals; every uncited scale number in this answer is an explicit design assumption.

The four architectural planes

1. Content plane: threads, posts, edits, deletions, attachments — durable, strongly consistent per aggregate.
2. Voting plane: vote capture, deduplication, score counters, anti-fraud weighting — high write rate, tolerant of short staleness.
3. Ranking plane: hot/top/new/controversial computation, listing materialization, cache refresh — derived, eventually consistent.
4. Governance plane: moderation actions, reports, trust levels, reputation, audit — low volume, high consequence, strongly consistent and auditable.

A strong answer keeps these planes separate: the voting plane may degrade to buffered writes while the content plane stays transactional, and the ranking plane may lag by a minute without anyone noticing.