Design a Real-Time Polling Platform

Problem statement

Design a real-time polling platform where users create polls with a question and multiple choices, participants vote in seconds, and every viewer sees live results as bar charts and percentages that move while they watch. The brief requires poll creation, real-time vote submission and counting, dynamic result display, and optional scheduling or expiration, while thousands vote simultaneously, results push with low latency, double voting is prevented, and votes may be anonymized.

This is not a CRUD app with a chart. A polling platform is a distributed-systems stress test in miniature: it combines a write-hot counter (one poll can absorb tens of thousands of votes per second), a read-hot fan-out (hundreds of thousands of viewers subscribe to the same tally), a correctness invariant (one person, one vote, exactly once), and a time-bounded lifecycle (polls open, close, expire, and must produce an exact final result). Each of these four forces pulls the architecture in a different direction, and the interview is won by separating them instead of fusing them into one database row.

Why the problem is distinctive

A news feed is read-hot but write-cool: many readers, many writers, no single hot key. A poll is the opposite. The tally for poll P is a single logical counter that a viral event can hammer at 10K writes per second, while the same counter is read continuously by every connected viewer. A naive design runs UPDATE tallies SET count = count + 1 on one row and serializes the entire viral event behind a single row lock; a naive delivery design pushes one WebSocket message per vote and floods every client and broker. The strong answer names both traps in the first two minutes and replaces them with append-only ledgers, sharded or streamed aggregation, and coalesced fan-out.

The second distinctive property is the split between live truth and final truth. While a poll is open, viewers tolerate a tally that is up to one or two seconds stale as long as it is monotonic and honestly labeled. When the poll closes, the platform must publish an exact result reconciled from the durable vote ledger. Live results are therefore an eventually consistent projection; the ledger is the source of truth. Saying this sentence early, and attaching a consistency model per dataset, is the single highest-signal move in this interview.

The four architectural planes

1. Intake plane: authenticated vote acceptance, eligibility checks, duplicate-vote rejection, durable append to the vote ledger, and acknowledgement semantics under retry.
2. Aggregation plane: turning a firehose of vote events into per-choice tallies using counter shards or windowed stream aggregation, protecting hot keys, and reconciling exact totals at close.
3. Delivery plane: live result fan-out over WebSocket or server-sent events with per-poll coalescing, freshness metadata, fallback polling, and a final push at close.
4. Governance plane: scheduling and expiration with durable timers, abuse and Sybil control, anonymity and privacy separation, retention, and audit.

Public operating baseline versus design assumptions

Public products prove the category. Twitter launched polls in 2015 with up to four choices and one vote per account, later extending duration to seven days, and has reported on the order of 200 million monetizable daily active users and roughly half a billion tweets per day, which sets the envelope for vote bursts riding on viral posts. Instagram Stories polls update live while hundreds of millions of daily story viewers watch. LinkedIn polls run inside a feed served to over one billion members on an architecture built around Kafka, which LinkedIn originated. Discord shipped native polls to a platform whose engineering blog describes storing trillions of messages and maintaining millions of concurrent gateway sockets. These are cited, company-reported facts used for context; every capacity number in this answer that is not cited is an explicitly stated design assumption.

For sizing, this answer assumes a mature platform with 100 million DAU, 2 million polls created per day, 200 million votes per day, a 20x viral peak multiplier, single hot polls absorbing 10K votes per second, and 250 thousand concurrent live-result sessions. The architecture that follows is built to keep the ledger exact, the live tally fresh, and the fan-out cheap under exactly that load.