Design a Global Mass-Audience Live Event Chat and Presence Platform
You are designing the real-time messaging and presence system for a global video streaming platform hosting mega-events (e.g., World Cup finals or esports championships). A single live stream channel can reach up to 10 million concurrent viewers in a single chat room. Viewers send chat messages, view active channel presence counts, receive instant automated moderation, and expect sub-500ms delivery of global chat activity. The core technical hurdle is handling the massive fanout volume and hot partition bottleneck of a single mega-channel without causing cascading network failure at the connection gateways or overwhelming client devices.
- Publish and deliver chat messages to all connected viewers in a live event channel within sub-500ms latency.
- Maintain real-time presence (active viewer counter and online user status) across multi-region edge nodes.
- Apply automated real-time message moderation and user rate-limiting prior to public broadcast.
- Provide chat message history backfill for users joining mid-stream or reconnecting after network drops.
- End-to-end global latency under 500ms p99 for chat broadcast.
- High availability (99.99%) for edge persistent connection management.
- Horizontal scalability supporting 10M concurrent WebSockets per channel and 50k inbound messages/sec.
- Graceful degradation and backpressure shedding during unexpected traffic surges.
10 million concurrent WebSocket connections per mega-channel. Peak inbound message rate of 50,000 messages/sec per channel. Aggregated fanout bandwidth requires multi-tiered edge infrastructure delivering 500 Gbps+ total downstream payload.
- High-level system topology diagram showing edge connection gateways, fanout trees, and ingestion pipelines.
- Detailed design for the hierarchical pub/sub fanout tree handling the hot channel problem.
- Data ingestion, presence aggregation, and storage model for real-time viewer counting.
- Backpressure, client-side sampling, and slow-consumer handling architecture.
Designs a multi-tiered fanout architecture (Ingestion -> Regional Distributers -> Edge Connection Gateways) rather than relying on a flat pub/sub broker like raw Kafka or Redis to avoid broker network interface or CPU saturation during single-channel spikes.
Avoids per-connection database/Redis writes on join/leave/heartbeat; employs local edge counter batching, sliding window aggregators, or HyperLogLog datastructures to emit delta updates upstream periodically.
Decouples message ingestion sharding from chat-room logical IDs, using message sequence numbering and distributed queue worker pools to prevent a single hot channel from bottlenecking a single queue partition.
Defines explicit strategies for high-frequency chat shedding/sampling (e.g., server-side message sampling or client UI frame-rate capping at 20 msg/sec) while preserving 100% of messages in durable storage for audit and moderation.
Positions real-time text filter/ML moderation services directly in the low-latency ingestion path before broadcasting, with strict circuit breakers to allow fallback under high latency.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Follow-up: How does your system adjust fanout delivery when a client device on a constrained mobile network falls behind, and how do you ensure edge gateways don't run out of memory buffering messages for slow consumers?
Must support 10,000,000 concurrent viewers in a single channel, sustain 50,000 inbound chat messages per second during peak moments, deliver messages with sub-500ms p99 end-to-end latency globally, and keep presence count updates accurate within 5 seconds without crashing storage layer on massive join/leave spikes.
- Views
- 35