Live polling and Q&A systems let a presenter ask a question to a large audience and see aggregated results appear on screen within a second or two, while attendees simultaneously submit and upvote questions for the speaker. What looks like a simple feature — a bar chart that updates itself — is actually a distributed systems problem that combines high-fan-in write traffic, high-fan-out read traffic, real-time aggregation, and strict ordering and consistency guarantees, all under a hard latency budget.

The category traces its roots to classroom “clicker” devices used in the 1990s and 2000s, where students pressed physical remotes to answer multiple-choice questions and a base station tallied the results. As internet connectivity became ubiquitous, this evolved into web and mobile based tools. Products like Poll Everywhere, Mentimeter, and Slido popularized browser-based live polling for conferences and classrooms in the 2010s. When the COVID-19 pandemic forced conferences and town halls to go fully virtual almost overnight, these tools had to scale from hundreds of participants in a room to tens of thousands of attendees spread across the globe, joining from browsers, mobile apps, and embedded webinar platforms simultaneously — a jump of two to three orders of magnitude in a very short time.

That scaling jump exposed the real engineering challenge: it is easy to build a poll that works for 50 people using a single server and a SQL UPDATE ... SET count = count + 1 statement. It is extremely difficult to build one that works for 50,000 people voting within the same 10-second window, where every single vote should be reflected in an aggregated result broadcast to every attendee’s screen with sub-second latency, without melting your database.

Before drawing boxes and arrows, a senior architect nails down what “large-scale virtual event” actually means numerically, because the design decisions for 500 concurrent users are entirely different from those for 50,000.

Functional Requirements

• Presenters can create polls (multiple choice, word cloud, rating scale, open text) tied to a live event/session.
• Attendees submit votes/answers in real time; each attendee can vote once per poll (or per allowed number of times, e.g. multi-select).
• Aggregated results (counts, percentages, word cloud weights) update on presenter and attendee screens in near real time.
• Attendees submit Q&A questions; other attendees upvote questions; the moderator/presenter sees the ranked question list live.
• Moderators can moderate content (hide/delete inappropriate questions, close polls).
• Historical results are available after the event for export/reporting.

Non-Functional Requirements

• Scale: 50,000+ concurrent attendees in a single session; bursts of tens of thousands of votes within a 5–10 second window when a poll opens.
• Latency: Aggregated result updates should reach clients within roughly 500ms–2s of a vote being cast (perceived as “instant” but not literally real time to the millisecond).
• Consistency: Exactly-once (or effectively-once) counting per attendee per poll — no double counting, no silently dropped votes; approximate/eventually-consistent aggregate display is acceptable, but the final tally after poll close must be exact.
• Availability: The system must not go down mid-event; events are scheduled, non-negotiable, and failures are highly visible (a stalled poll on a 20,000-person livestream is a very public incident).
• Fan-out efficiency: One aggregated update must reach tens of thousands of open connections without linear cost per attendee on the write path.
• Abuse resistance: Prevent bots/scripts from stuffing votes or spamming Q&A.

Sizing the Problem in Numbers

System design interviews reward turning vague requirements into a rough numeric model early. A reasonable working set of assumptions for “a large virtual event”:

These numbers matter because they immediately rule out naive approaches: 8,000 writes/sec against a single relational row, or 50,000 clients polling an HTTP endpoint every second (which alone is 50,000 req/sec of pure waste), are both non-starters at this scale — which is exactly why the architecture below leans on stream processing and push-based fan-out from the outset rather than retrofitting them after a proof-of-concept falls over.

At a high level, the system separates the “hot path” (votes flowing in, results flowing out, both needing to be fast and horizontally scalable) from the “control path” (poll creation, moderation, historical reporting, which can tolerate normal request/response latency and standard CRUD patterns).

Component Breakdown

• CDN / Edge: Serves static assets (JS bundles, poll UI) close to attendees globally, reducing load-time latency and offloading the origin.
• Global Load Balancer: Routes attendees to the nearest healthy regional cluster; performs TLS termination and DDoS scrubbing.
• API Gateway (REST/HTTP): Handles stateless request/response operations — poll creation, fetching poll definitions, authentication, historical data.
• WebSocket Gateway Cluster: Holds the long-lived, persistent connections attendees use to receive real-time updates (or Server-Sent Events / long-polling as a fallback). This tier is deliberately stateless regarding business logic — it only manages connections and subscriptions to broadcast topics.
• Rate Limiter / Abuse Filter: Sits in front of ingest to reject duplicate votes, throttle per-connection request rates, and catch obvious bot patterns before they hit the streaming backbone.
• Vote / Q&A Ingest Services: Stateless services that validate a vote or question (Is the poll open? Has this attendee already voted? Is the attendee actually registered for this event?) and publish an event to the streaming backbone.
• Partitioned Message Broker (Kafka/Kinesis-style): The backbone that decouples ingest from aggregation. Votes for a given poll are partitioned (e.g., by poll_id) so ordering per poll is preserved and aggregation workers can consume in parallel across partitions.
• Stream Aggregation Workers: Consume the vote/question stream and maintain running aggregates (counts per option, top-N ranked questions) using approximate, mergeable data structures.
• In-Memory Aggregate Store (Redis Cluster): Holds the current “hot” aggregate for each active poll, using atomic counter/sorted-set operations for very low-latency reads and writes.
• Pub/Sub Broadcast Service: Takes a computed aggregate snapshot (or delta) and fans it out to every WebSocket gateway node subscribed to that poll’s topic, which then pushes to individual client connections.
• Durable Vote Log (Cassandra/DynamoDB-style wide-column store): The append-only source of truth for every individual vote/question — used for exact final tallies, audits, and replay/recovery.
• Metadata DB (PostgreSQL): Stores structured, low-volume, relational data — events, sessions, polls, users, moderation state.
• Analytics Store (ClickHouse/BigQuery): Receives the full event stream for post-event reporting, funnel analysis, and export — decoupled from the real-time path so heavy analytical queries never compete with live traffic.

The key internal insight is that the system never tries to update “the chart” directly from a vote. Instead it treats voting as a stream-processing problem: individual events flow through a pipeline that continuously folds them into a small, cheap-to-broadcast summary.

Idempotency and Exactly-Once Semantics

Each vote carries a deterministic idempotency key, typically hash(attendee_id, poll_id) (or including an option_id for multi-select polls where an attendee is allowed several distinct picks). Before a vote is admitted, the ingest service checks a fast idempotency store (Redis SETNX or a similar atomic “set if not exists”) keyed on that identifier. If the key already exists, the vote is treated as a duplicate/resubmission (common with flaky mobile networks retrying a request) and acknowledged without being counted twice. This single check is what prevents the most common correctness bug in these systems: a user’s spotty connection causing their client to retry a vote submission, which without idempotency would silently double their vote’s weight in the final tally.

Mergeable Aggregates (CRDTs and Approximate Counters)

Because multiple aggregation workers process different partitions of the same poll’s vote stream in parallel, the aggregate data structure must be safely combinable regardless of the order updates arrive in. This is the classic use case for CRDTs (Conflict-free Replicated Data Types) — specifically G-Counters (grow-only counters) or PN-Counters for vote tallies per option, which guarantee that merging partial counts from different workers, in any order, any number of times, produces the same correct total. For Q&A upvote ranking, a common technique is a probabilistic top-K structure (or simply per-question atomic counters combined with a periodic re-sort) since exact real-time global ranking of tens of thousands of questions is unnecessary — only the top ~20 questions the moderator will actually look at matter for the live view.

Push vs. Pull for Result Delivery

Attendee clients do not poll an HTTP endpoint every second to check for new results (that pattern collapses under tens of thousands of concurrent polling clients). Instead, clients hold a persistent WebSocket (or SSE) connection and are pushed a compact delta or snapshot whenever the aggregation layer decides it’s time to publish — typically on a fixed cadence (e.g., every 500ms–1s) rather than on every single vote, which smooths out the fan-out load and avoids “flickering” numbers on screen.

Topic-Based Subscription Model

Each active poll maps to its own logical broadcast topic (e.g. event:{event_id}:poll:{poll_id}). A client subscribes to the topic(s) relevant to whatever it’s currently viewing and unsubscribes when it navigates away or the poll closes, so gateway nodes never waste bandwidth pushing updates for content a given client isn’t looking at. This topic-per-poll granularity is also what makes multiple simultaneous polls within one event (common in breakout sessions) tractable — each has an entirely independent aggregate, partition set, and broadcast topic, with no shared mutable state between them.

Delta vs. Full Snapshot Broadcasts

Two broadcast strategies are used depending on payload size: for a small, fixed poll (e.g., four multiple-choice options), it’s simplest and cheapest to just broadcast the full current tally every interval — the payload is tiny and clients need no reconciliation logic. For larger result sets (a Q&A ranked list of dozens of questions, or a word cloud with hundreds of distinct terms), sending only the delta since the last broadcast (which items moved, new items that entered the top-K) keeps payload size roughly constant regardless of how large the underlying dataset grows, at the cost of slightly more complex client-side state reconciliation and the need for periodic full-snapshot resyncs to correct any drift from a missed delta.

Here is the end-to-end journey of a single vote — from the tap on an attendee’s phone all the way to every subscribed screen refreshing the chart.

Notice the client receives a fast acknowledgement (their vote was accepted) separately and much sooner than the aggregate update that reflects it on everyone’s chart. This separation is what allows the ingest path to stay low-latency (a few tens of milliseconds) while the fan-out path batches on a coarser cadence for efficiency — the two are deliberately decoupled.

Poll Lifecycle States

1. Draft — created by presenter, not visible to attendees.
2. Open — broadcast to attendees, ingest path accepts votes, aggregation workers actively publishing updates.
3. Closed — ingest path rejects further votes (idempotently, so late/duplicate network retries are simply dropped); a final, exact tally is computed by reading the durable vote log directly (bypassing any approximate/streaming shortcuts) to guarantee the displayed final number is authoritative.
4. Archived — results persisted for post-event reporting; hot data evicted from Redis to reclaim memory.

This is usually the section that differentiates a strong system design answer from a mediocre one, because it’s where the actual “hard” engineering happens.

Why Sharded, Approximate Aggregation Beats a Single Source of Truth Counter

A single row in a relational database with vote_count = vote_count + 1, hit by 10,000 concurrent requests, serializes on row-level locks and becomes the system’s bottleneck almost immediately — you’d be lucky to sustain a few hundred updates per second before latency spikes. The fix is the same pattern used by high-traffic counters everywhere (think “like” counts on major social platforms): split the counter into N independent shards (e.g., 16 or 64 per poll option), let writers increment a random shard, and sum the shards only when a reader needs the total. Writes become embarrassingly parallel; reads pay a small, bounded summation cost.

Windowed vs. Cumulative Aggregation

For simple vote counts, aggregation is cumulative — every vote ever cast for an option contributes to its running total for the poll’s lifetime. For “trending questions” or momentum-based ranking in Q&A (upvotes gained in the last 2 minutes matter more than upvotes from 20 minutes ago), a sliding time-window aggregation (e.g., an exponentially decayed score, or a fixed tumbling-window count) is more appropriate, similar to how trending-topic systems weight recency.

Backpressure Handling

When a poll opens to 50,000 attendees simultaneously, the ingest rate can spike far above steady-state. The message broker’s partitioned, durable log acts as a shock absorber — the ingest tier can accept and durably queue votes faster than the aggregation tier consumes them, and consumers catch up at their own sustainable pace without data loss. This is the classic producer/consumer decoupling benefit of a log-based broker over a direct RPC call from ingest straight into an in-memory aggregator.

Word Clouds and Open-Text Aggregation

Word-cloud style polls (attendees type free-text answers, and the most common words/phrases render larger) add a normalization step ahead of aggregation: incoming text is lowercased, trimmed, and mapped through a light stemming/synonym pass (so “Cloud,” “cloud,” and “clouds” collapse into one bucket) before being fed into a sharded frequency counter identical in spirit to the multiple-choice vote counters. Because the space of possible answers is unbounded (unlike a fixed set of poll options), the aggregation layer typically tracks only an approximate top-N frequent terms using a space-saving/count-min-sketch style structure rather than an exact count for every distinct word ever submitted, which keeps memory bounded even if attendees submit thousands of unique responses.

Consistency Model, End to End

It’s worth being explicit about exactly which consistency guarantee applies at each stage, since “eventually consistent” is often used too loosely in interviews:

This tiered approach — relaxed consistency where it’s cheap and unnoticed, strict consistency exactly where it’s visible and consequential — is a recurring theme in large-scale real-time systems and a strong signal in an interview that a candidate isn’t reaching for “just make everything strongly consistent” as a default.

Every design choice above buys something and costs something. Naming both explicitly is what turns an interview answer from a laundry list into a defensible design.

At the target scale (tens of thousands of concurrent attendees, bursts of tens of thousands of votes within seconds), performance work concentrates on three specific bottlenecks.

Connection Scale on the WebSocket Tier

A single modern server can typically hold on the order of tens of thousands to around a hundred thousand idle-ish WebSocket connections, depending on message frequency, heap/connection overhead, and OS tuning (file descriptor limits, ephemeral port ranges, kernel socket buffer tuning). For 50,000+ concurrent attendees, the gateway tier is horizontally scaled behind a load balancer that supports sticky/consistent routing, with connection state kept minimal (essentially just “which topics is this socket subscribed to”) so any gateway node is interchangeable and stateless from the app’s perspective.

Fan-out Cost Control

Broadcasting to 50,000 sockets from a naive single publisher is itself a scaling problem. The standard fix is a pub/sub fan-out tree: the aggregation layer publishes one message per poll update to a topic; a layer of broadcast/relay nodes subscribed to that topic each push to their own local shard of connected clients, turning an O(N) fan-out from a single node into a distributed, parallel fan-out across many gateway nodes, each handling only its own slice of connections.

Hot Partition / Hot Poll Problem

If a single, wildly popular poll dominates traffic (which is the common case — one poll open at a time to the whole audience), naive partitioning by poll_id alone concentrates all traffic on one partition. The fix is composite partitioning, e.g. hash(poll_id, attendee_id) % N, spreading a single poll’s vote stream across many partitions and many aggregation workers, then merging (which is safe and cheap thanks to the CRDT/shard-counter design above).

Thundering Herd on Poll Open

The single sharpest spike in the entire system is the moment a presenter clicks “launch poll”: tens of thousands of clients receive a near-simultaneous WebSocket push telling them a new poll is available, and a large fraction submit a vote within the same one-to-two second window as their UI renders and they tap an answer. Two mitigations are standard: (1) the “poll opened” notification itself is fanned out through the same pub/sub tree used for results, so it scales the same way results do, and (2) client-side jitter — deliberately adding a few hundred milliseconds of random delay before the very first UI interaction becomes possible, or simply relying on natural human reaction-time variance — smooths what would otherwise be a single-instant spike into a slightly wider window, reducing peak instantaneous load on ingest.

Connection Scaling Math

If a single gateway node comfortably sustains 20,000 persistent connections with periodic (sub-second) broadcast traffic, 50,000 attendees requires at least 3 gateway nodes at capacity — but production sizing adds headroom for (a) uneven load balancing across nodes, (b) at least N+1 (ideally N+2) redundancy so a single node failure doesn’t cause a connection drop cascade onto already-full neighbors, and (c) reconnect storms, where a large fraction of clients reconnect within a short window after any gateway restart or network event — meaning real-world capacity planning for 50,000 attendees often provisions for 5–6 nodes’ worth of headroom, not the bare-minimum 3.

Events are scheduled and non-negotiable — going dark mid-keynote is a public incident. Reliability engineering here is not paranoia; it is table stakes.

• Stateless gateways and ingest services: Any node can be killed and replaced without losing in-flight business state, since durable state lives in the broker, the vote log, and Redis — enabling rolling deploys and fast auto-healing.
• Multi-AZ (and ideally multi-region) broker and cache clusters: The message broker and Redis cluster are deployed across availability zones with replication, so a single zone outage doesn’t halt an in-progress event.
• Graceful degradation ladder: If the aggregation layer falls critically behind or Redis is unhealthy, the system degrades to showing “last known good” results with a subtle staleness indicator, rather than showing an error or blank chart — availability of a slightly-stale answer beats unavailability.
• Client-side reconnect with exponential backoff and jitter: WebSocket clients automatically reconnect and resubscribe on drop, with backoff to avoid a reconnect storm overwhelming gateways right after a network blip or gateway restart.
• Circuit breakers between tiers: The ingest service trips a circuit breaker to shed load (returning a fast, honest “try again” instead of votes queueing indefinitely) if the broker is unreachable, protecting upstream clients from cascading timeouts.
• Idempotent replay for disaster recovery: Because the vote log is the source of truth and aggregation is a pure, deterministic function over it, the entire aggregate state for any poll can be rebuilt by replaying the log — a powerful recovery mechanism if the cache layer is lost entirely.

Disaster Recovery Runbook, Conceptually

A well-designed system in this space treats “the aggregation cache is gone” as a routine, rehearsed scenario rather than a five-alarm emergency, precisely because the architecture was built with that recovery path in mind from day one:

1. Detect via consumer lag and cache health alerts crossing threshold, or an outright node/cluster failure signal.
2. Ingest continues accepting and durably queuing votes to the broker without interruption — this tier has no dependency on the cache being healthy.
3. Gateways serve the last known-good snapshot to connected clients with a subtle “updating” indicator rather than an error state, preserving perceived availability.
4. Once the cache layer is restored (new nodes, failover to a replica, or a fresh cluster), aggregation workers resume consuming from their last committed broker offset and rebuild the in-memory aggregate by replaying events forward — an operation bounded by however much backlog accumulated during the outage.
5. Once aggregation workers report caught up (lag back near zero), the fan-out layer resumes normal-cadence broadcasting and the “updating” indicator clears.

The critical property enabling this whole runbook is that the aggregate is always a deterministic, replayable function of the durable log — nothing about recovery requires guessing or manual data reconciliation.

Public, time-boxed, high-visibility events are an attractive target. Security here is layered defense across identity, ingest, transport, moderation, and the edge.

Threat Model Summary

Q&A Moderation Pipeline

Open-text Q&A deserves its own mini-pipeline distinct from vote ingest, because it carries reputational risk that a wrong multiple-choice vote count simply doesn’t: a single offensive question broadcast to 50,000 attendees on a company’s public town hall is a real incident. A layered approach is standard: (1) a fast, automated classifier screens submissions synchronously and blocks the most clearly disallowed content before it’s even stored; (2) borderline content is queued for a human moderator, visible only to the moderator until approved; (3) approved content becomes visible to the full audience and enters the same upvote-ranking aggregation pipeline as any other question; (4) a “report” action lets attendees flag already-visible content for expedited moderator review, since no automated filter catches everything.

You can’t operate a system like this from an intuition; you operate it from dashboards, traces, and calendar-aware alerts that know when an event is live.

• Golden signals per tier: latency, traffic (votes/sec, active connections), error rate, and saturation (broker consumer lag, Redis memory/CPU, connection count vs. capacity) tracked separately for ingest, aggregation, and fan-out.
• Consumer lag as the critical leading indicator: Message broker consumer lag for the aggregation workers is the single most important metric — rising lag is the earliest, clearest signal that live results are about to fall visibly behind reality.
• End-to-end latency tracing: Distributed tracing (with a correlation ID attached at vote submission) to measure the full path from “vote accepted” to “reflected in a broadcast the client received,” not just the isolated latency of a single hop.
• Real-user monitoring (RUM): Client-side timing of “time from tap to seeing the chart move” captured from actual attendee devices, since server-side metrics alone can miss client network/rendering delays.
• Structured, sampled event logging: High-cardinality vote/question events are logged in a structured, sampled way to the analytics store, avoiding the cost of logging every single event at full fidelity to a system meant for debugging.
• Alerting thresholds tied to event calendars: Since load is extremely spiky and tied to scheduled events, static always-on alert thresholds create noise; alerting is often tied to “is an event currently live” context to distinguish real incidents from expected idle-period quiet.

Example SLOs

Because traffic is spiky and event-scheduled, deployment strategy is inseparable from the event calendar.

• Container orchestration (Kubernetes): Stateless services (ingest, gateway, aggregation workers) run as horizontally scalable Deployments with Horizontal Pod Autoscaling driven by custom metrics like votes/sec and connection count, not just CPU.
• Pre-scaling / scheduled scale-up: Because major events are scheduled in advance, capacity is often proactively scaled up ahead of a known event start time rather than relying purely on reactive autoscaling, which can lag behind an instantaneous traffic cliff-edge at “poll opens.”
• Managed streaming and cache services: Using a managed Kafka/Kinesis-equivalent and managed Redis/ElastiCache-equivalent reduces operational burden for the stateful backbone components that are hardest to run reliably in-house.
• Multi-region deployment for global audiences: Regional gateway clusters close to attendee geography reduce WebSocket latency; the aggregation/streaming backbone can be regional-per-event (simplest) or globally replicated for events with a truly global, latency-sensitive audience.
• Blue-green or canary deploys, never mid-event: Deployments of the hot-path services are scheduled around the event calendar — rolling out a change to the aggregation service five minutes before a 50,000-person keynote poll is a well-known way to cause an incident.

Cost Optimization

Traffic for this kind of system is extremely spiky and largely idle between scheduled events, which makes naive “always provisioned for peak” capacity wasteful. Common cost levers include: scaling stateless tiers (gateway, ingest, aggregation workers) down to a small baseline outside event hours and scaling up ahead of scheduled start times; using spot/preemptible capacity for aggregation workers where possible, since they’re stateless and can be replaced without data loss thanks to the durable log; and tiering storage so that hot, actively-queried data (the currently open poll) sits in memory while closed-event historical data moves to cheaper, colder storage after some retention window, keeping the expensive in-memory cache small and fast rather than growing unbounded across every event the platform has ever hosted.

Multi-Tenancy Considerations

A platform serving many customers’ events simultaneously (as opposed to a single internal deployment) needs the architecture above applied per-tenant with careful isolation: partition keys and cache keys are always namespaced by event_id (and often by customer/org ID above that), noisy-neighbor protection ensures one customer’s viral 100,000-attendee event doesn’t starve resource quota from a dozen smaller concurrent events on shared infrastructure, and rate limits and quotas are enforced per tenant rather than globally so abuse or a runaway bug in one customer’s integration can’t degrade the platform for everyone else.

Different data has different access patterns; using one store for everything is exactly the trap this design avoids.

Load balancing operates at two distinct layers: a standard L4/L7 load balancer distributes initial HTTP and WebSocket-upgrade requests across gateway nodes (often with consistent hashing so a reconnecting client tends to land near the same broadcast group, improving cache locality); and a separate, logical “topic-to-node” mapping in the pub/sub layer ensures broadcast fan-out work is spread evenly across gateway nodes rather than concentrated on whichever node happened to receive the aggregation service’s publish call.

Two protocols, two very different jobs — and internal services drawn along the same fault lines they’ll fail along.

Every real production system is a chosen set of patterns and an avoided set of anti-patterns. Name them explicitly.

Patterns Used

Anti-patterns to Avoid

The design above is only as good as its operational habits. These are the disciplines that separate an event that runs boringly from one that trends on social media for the wrong reasons.

No two production systems in this space are built identically, but the recurring architectural DNA — decoupled ingest, sharded/mergeable aggregation, and push-based fan-out over persistent connections — shows up consistently across the industry, because it’s a direct consequence of the same underlying constraints (high fan-in, high fan-out, tight latency budget) rather than any single company’s specific implementation choice.

The questions candidates and product managers actually ask, answered honestly.

The whole design is a composition of well-known patterns matched carefully to the specific shape of the workload — a bursty, high-fan-in write spike followed immediately by a sustained, high-fan-out read pattern to the same population.

Pulled together, none of these individual pieces — a message broker, a sharded counter, a pub/sub fan-out tree — is exotic on its own. What makes this a genuinely interesting system design problem is composing them correctly around the specific shape of the workload: a short, extremely bursty write spike from tens of thousands of independent sources, immediately followed by a sustained, high-fan-out read pattern to the same population, all under a latency budget tight enough that the result still feels “live” to a room full of people watching a shared screen.