Design a Polling or Voting Chat

Problem statement

Design a polling and voting feature embedded in a real-time group chat platform. Any participant can create a poll with a question and a set of options, optionally allowing multiple picks, optionally anonymous, and optionally time-bound. Every participant watching the conversation must see dynamic bar-chart results update in near real time as votes arrive. The creator gets a highlight or notification when the poll is live and when it closes. Some polls are ephemeral and vanish with the room; others must remain auditable.

This looks like a small feature because the UI is small: a question, some bars, a vote button. The engineering is not small. A vote is a one-person-one-ballot transactional write that must be exactly-once per user and per poll. A result display is a high-fanout read projection that must stay fresh for thousands or hundreds of thousands of concurrent viewers. A poll can be created in any room, which means the write hot key is unpredictable: one poll in a 300,000-member broadcast room can absorb thousands of votes per second while every other poll is idle. And anonymity, when offered, must be real at the data-model level, not a UI checkbox: the platform must prove a user voted without revealing what they chose.

Why this problem is distinctive

A chat message is append-only and tolerant of eventual ordering. A vote is not. If two replicas accept conflicting ballots, or if a retry double-counts, the result is wrong in a way users can verify and dispute. If the tally projection lags by thirty seconds during a live event, the feature feels broken even though the ledger is correct. The design therefore separates three planes that weaker answers merge: the ballot ledger (strongly consistent, exactly-once), the tally projection (eventual, coalesced, freshness-labeled), and the anonymity boundary (structural separation of who-voted from what-was-chosen).

The problem requires poll creation with options, real-time tally and display, ephemeral or time-bound polls, creator notification, scalability for large groups, consistency against double voting, low-latency bar-chart updates, and audit or logging for transparency. It also asks for depth where typical prep material stays shallow: vote concurrency, unique-user constraints, partial anonymity, and live result display. This answer treats those four areas as the core of the design rather than footnotes.

Public context versus design assumptions

The category is operationally proven. Telegram ships native polls and quizzes with anonymous, visible, and quiz modes across a messenger that reports close to one billion monthly users. Discord introduced native polls in 2024 with multiple answers and time bounds up to one week. Kahoot reports billions of cumulative game participations and runs single live events with very large concurrent audiences. X (formerly Twitter) polls have recorded tens of millions of votes on a single question. These are company-reported public figures and set context only.

For capacity planning, this answer assumes a mature chat platform with 60 million monthly active users, 12 million daily active users, 300,000 rooms, and 1.8 million concurrent WebSocket connections at global peak. Poll workload assumptions: 150,000 polls created per day, 8 million votes per day average, a 5x evening peak, and a worst-case event poll receiving 50,000 votes inside 60 seconds. Unless tied to a named company, every number in this answer is an explicitly stated assumption, target, or budget.

The three architectural planes

1. Ballot plane: idempotent vote intake, exactly-once per user and poll, strongly consistent per poll aggregate, durable ledger.
2. Projection plane: tally counters, room-scoped fanout, coalesced bar-chart updates, presence-aware delivery, graceful staleness.
3. Trust plane: anonymity boundary, creator audit rights, moderation at the architecture level, evidence retention.

A strong interview answer names these planes in the first five minutes. It allows the projection plane to degrade under load without weakening the ballot plane, and it lets the trust plane verify a result without exposing ballots.