Design a Real-Time Reaction/Emoji Stream

Problem statement

Design a platform that lets viewers of a live video (or a freshly published post) tap emoji reactions and see them reflected instantly: floating hearts over the stream, a live counter per emoji, and a reaction timeline that can be replayed against the content. The system must capture taps in real time, aggregate them per room, broadcast updates to every connected viewer, render a floating overlay, and correlate reactions to the content timeline so a replay shows the bursts at the right moments.

The distinctive difficulty is the arithmetic of amplification. A single tap is a write; making it visible to N viewers is a fan-out of N. In a hot room with one million viewers and a climactic moment, naive per-tap fan-out produces 100,000 writes/sec inbound and 100,000,000 frame deliveries/sec outbound. No architecture survives that without shaping. The design therefore separates three planes:

1. Ingestion plane: authenticated, rate-limited tap capture with client-side coalescing. Taps are cheap, loss-tolerant, and batchable.
2. Aggregation plane: per-room, per-emoji windowed counters that turn a firehose of taps into a small, periodic truth (deltas and totals).
3. Distribution plane: room-scoped broadcast of aggregate deltas plus a bounded sample of individual reactions, from which clients synthesize the floating overlay.

The key invariant: the viewer experience must degrade in a designed order. Individual floating hearts are decorative and are shed first; aggregate counts and totals are the product truth and are preserved longest. A reaction system that drops 10% of decorative floats under load is healthy; one that loses the counter or stalls the stream overlay is broken.

This is not a chat system. Reactions are tiny, high-rate, mostly anonymous signals with no ordering guarantee between users and no durability requirement per tap. That changes every downstream choice: we aggregate at the edge, keep live state ephemeral with TTLs, persist only aggregates and samples, and let the client be the first shock absorber.

Public operating baseline versus design assumptions

Public figures establish that the category is real at scale. Instagram reports more than 2 billion monthly active users and its Live product popularized floating hearts. Discord has publicly described storing trillions of messages and sustaining millions of concurrent connections. Twitch sustains millions of average concurrent viewers with emote-heavy chat. These are cited, company-reported or publicly reported figures; they are context, not requirements for our fictional system. For capacity planning this answer explicitly assumes: 20 million DAU, 1 million peak concurrent live viewers, 10,000 concurrent live rooms at peak, 200K taps/sec baseline ingress, 1M taps/sec at a 5x event peak, and one hot room with 1M viewers producing 100K taps/sec. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

Why the problem is distinctive

A feed system is read-amplification heavy; a reaction stream is write- and fan-out-amplification heavy with an ephemeral truth. A chat system persists every message and orders it; a reaction system may sample, coalesce, and approximate. The interview win is showing you understand which guarantees are product-critical (visible liveness, monotonic totals, replay correlation) and which are decorative (every individual float), then building the degradation ladder around that distinction.