Design an Online Debate Platform

Problem statement

Design an online debate platform where users post debate topics, take explicit sides (pro/con or named stances), exchange structured arguments and counterarguments in time-boxed or point-boxed rounds, vote on the strongest arguments, and accumulate a public track record of debate performance. The product must support concurrent live debates, deep argument trees, reputation, moderation against abuse, and long-term search and archival of finished debates.

This is not a comment section with extra steps. Four structural properties change the architecture. First, arguments form a tree anchored to a side: every counterargument replies to exactly one parent argument, and the tree is a first-class object that must render, paginate, and stay consistent under concurrent writes. Second, debates are temporal workflows: rounds open and close, turns alternate, clocks tick, and deadlines must fire reliably even if the service that created them crashes. Third, votes are small but integrity-critical writes: one user, one vote per argument, changeable within policy, aggregated into public counts and into reputation, while resisting brigading and Sybil manipulation. Fourth, finished debates are permanent cultural artifacts: they must be searchable, archivable, restorable, and deletable under privacy law.

Why the problem is distinctive

A feed system optimizes fan-out and ranking. A chat system optimizes presence and ordering. A debate platform must do both while also enforcing workflow correctness (whose turn is it, is the round open, has this user already voted) and preserving an auditable reputation ledger. The read path is dominated by tree rendering and search; the write path is dominated by votes and live events; the correctness path is dominated by debate state transitions, vote uniqueness, and reputation accounting. Treating these as one undifferentiated CRUD app produces either an inconsistent debate or an unscalable one.

Public operating baseline versus design assumptions

Public evidence shows the category is real and large. Reddit's S-1 reported 73.1 million daily active uniques in Q4 2023, and its r/changemyview community runs structured persuasion debates with a delta-based reputation tracked by a public bot. Discord's engineering blog describes storing and indexing trillions of messages on Cassandra and later ScyllaDB for roughly 200 million monthly users. Stack Exchange built a global reputation and moderation model around 24 million questions and community voting. These are cited, company-reported figures; they are context, not requirements.

For capacity planning this answer explicitly assumes a mature platform with 30 million registered users, 3 million DAU, 40,000 new debates per day, 400,000 arguments per day, 1.2 million votes per day, and 250,000 peak concurrent live-debate viewers with a 5x event peak. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

The four architectural planes

1. Debate workflow plane: durable state machines for debate, round, turn, and closure; timer authority; side and stance assignment.
2. Argument and vote plane: the argument tree, vote uniqueness, count aggregation, ranking, and reputation ledger.
3. Live experience plane: WebSocket fan-out, presence, turn notifications, live vote ticks, and hot-debate overload control.
4. Trust plane: moderation pipeline, Sybil and brigading resistance, privacy deletion, audit, and search/archive governance.

A strong interview answer keeps these planes separate: the live plane may degrade (stale vote ticks, hidden presence) without weakening the workflow plane (round deadlines, vote uniqueness, reputation correctness).