Design a Live Audience Reaction for TV

Problem statement

Design a live audience reaction platform for a TV or streaming show. While watching a live broadcast, viewers tap reaction buttons (heart, laugh, applause, shock, a custom show emoji) on a second-screen mobile app. The platform ingests those taps from potentially millions of concurrent viewers, deduplicates and rate-limits them, aggregates them into counts and rates in real time, and pushes a summary or an animation to the on-air broadcast graphics so the host and the home audience can see the crowd respond.

The brief's four functional requirements and four non-functional requirements drive everything: mass taps, aggregation with rate-limiting, a real-time visualization or scoreboard, optional region or demographic breakdown, massive concurrency, low latency to stay in sync with on-air content, fault tolerance, and possibly CDN-based ingestion.

Why this is not a normal counter

A web analytics counter can be eventually consistent and a few seconds stale. A reaction that drives on-air graphics cannot flicker, cannot visibly go backwards on live television, and must land at the exact moment the show expects it. This creates three tensions a naive design misses:

1. Bursty, skewed writes. Reactions are not steady. When the host says "tap the heart right now," a large fraction of the audience taps within 2-5 seconds. That is a spike of tens of thousands to hundreds of thousands of events per second, concentrated on one reaction type, one show, and one moment. A system sized for the average is destroyed by the peak.

1. Two different notions of truth. The ingestion path can tolerate loss and sampling (it is an experience effect). But the number displayed on air is a promise to the viewer; it must be monotonic, stable, and derived from a consistent aggregate. So we separate a lossy, high-throughput ingest plane from a smaller, strongly consistent broadcast-truth plane.

1. Time is part of correctness. A tap that arrives 8 seconds late because of network jitter may correspond to a moment that has already passed on air. The system must align tap timestamps to the on-air timeline, not just count whatever arrives.

Public operating baseline versus design assumptions

Public evidence shows the category is real and large. Twitch reported peak concurrent viewership in the tens of millions and a chat system that processes billions of messages per day, built on Go and the IRC protocol over WebSockets. The Eurovision Song Contest draws roughly 160 million television viewers whose national televotes are collected and verified inside a bounded voting window before being merged with jury scores on air. Twitter/X has publicized peak event rates above 140,000 posts per second during live broadcast moments. These are cited company-reported figures for context, not requirements for our fictional system.

For capacity planning this answer explicitly assumes a mature second-screen platform with 5 million registered viewers, 1.5 million simultaneously watching the flagship live show, and a 6x event spike when the host triggers a reaction moment. Unless a number is tied to a citation, it is a stated design assumption, target, or budget, not a claim about any company's private architecture.

The four architectural planes

1. Ingestion plane: accept, authenticate, deduplicate, and rate-limit massive tap bursts at the edge.
2. Aggregation plane: turn raw taps into per-reaction counts, rates, and region/demographic rollups over windows.
3. Broadcast plane: publish monotonic, aligned snapshots to the on-air graphics renderer with its own clock and render pipeline.
4. Governance plane: show configuration, reaction catalogs, anti-abuse policy, moderation, evidence, and analytics.

A strong answer keeps these planes separate. It lets the ingestion plane shed load without corrupting the broadcast-truth plane, and it lets the broadcast plane keep rendering a last-known-good snapshot if the backend degrades. The cloud never decides whether a single tap is "valid" in the hot path with a slow round trip; validation is cheap, local, and idempotent, and reconciliation happens downstream.