Design the backend for live comments and reactions on a broadcast — the scrolling stream of viewer messages and the burst of tap-to-send reactions (hearts, claps, laughs) that overlay a live video (think the chat rail on a big streaming event).

Operating context. A single popular broadcast draws up to 2,000,000 concurrent viewers who are overwhelmingly readers: nearly everyone watches the comment stream, a small fraction posts. Comments arrive at roughly 20,000 writes/sec at the peak of a hot moment (a goal, a product reveal), and reactions arrive as a far larger firehose — think 500,000 taps/sec — that no viewer needs to see individually. Every connected client must receive new comments within about 2 seconds. Reactions are shown as an aggregate ("12.4k hearts in the last few seconds"), never one animation per tap. Most sessions are read-only and long-lived over the length of the broadcast.

Out of scope. The video encode / delivery pipeline, the live-stream player, user auth and identity, the ML that classifies toxic text, gifting / paid super-reactions, and cross-broadcast search or archival analytics. Assume separate teams own those; you consume a broadcastId and an authenticated userId.

What to produce. A high-level architecture covering: the write path for a comment vs. the write path for a reaction, how the connection tier fans a comment out to millions of subscribers, how reactions are sampled and aggregated into a periodic count instead of fanned out per tap, the ordering guarantee you offer on the comment stream and what you trade for throughput, how a late-joining viewer backfills recent history, and where a moderation hook sits so a flagged comment can be withheld or removed. Sketch the major components and the flow between them; we will probe specifics at the checkpoints.