Design a Sports Score & Live Chat

Problem statement

Design a platform that displays real-time sports scores, game clocks, and play-by-play updates from external data providers, while simultaneously allowing millions of fans to chat about the match in real time. The system must handle extreme traffic spikes at key moments — goals, buzzer-beaters, final whistles — where concurrent users and message rates can multiply by 10x or more within seconds.

This is not a simple CRUD application. Two fundamentally different real-time workloads coexist: a low-volume, high-authority score ingestion pipeline where correctness and ordering are paramount, and a high-volume, lower-authority fan chat system where throughput, latency, and moderation dominate. Merging these into a single architecture without respecting their distinct consistency, latency, and failure semantics is the most common design mistake.

Why the problem is distinctive

A social media feed can tolerate seconds of delay. A payment system can tolerate retries. A live scoreboard during the World Cup Final cannot tolerate either: 1.5 billion viewers are watching, and a score update arriving 5 seconds late destroys trust. Simultaneously, when a goal is scored, chat volume can spike from 10,000 to 500,000 messages per second in under 2 seconds. The architecture must handle both the precision of score data and the volume of fan emotion.

The score pipeline is a narrow, ordered, authoritative stream: one source of truth, strict ordering, idempotent processing, and exactly-once semantics for state transitions. The chat pipeline is a wide, lossy-tolerant, high-throughput stream: millions of concurrent writers, content moderation, rate limiting, and graceful degradation under load. A strong design separates these planes completely.

The four architectural planes

1. Ingestion plane: Receives, validates, deduplicates, and orders score events from external sports data providers (Sportradar, Stats Perform, official league feeds). This is the single source of truth for match state.
2. Fan-out plane: Distributes validated score state changes to millions of connected clients via WebSocket, SSE, or long-polling. Handles subscription management, presence, and delivery guarantees.
3. Chat plane: Accepts, moderates, stores, and distributes fan messages. Handles rate limiting, profanity filtering, spam detection, and per-match channel isolation.
4. Operations plane: Monitoring, alerting, provider failover, content moderation review queues, and incident response for live events.

A strong interview answer keeps these planes separate. It allows the chat plane to degrade under load without affecting score delivery, and it permits the ingestion plane to fail over to a backup provider without interrupting fan connections.

Public operating baseline versus design assumptions

Public evidence establishes the scale of this category. Sportradar reports distributing data from 800+ sports federations covering 900,000+ events annually across 40+ sports. Stats Perform (Opta) collects over 3,500 data points per football match. ESPN's digital platform serves tens of millions of users during major events like March Madness and the Super Bowl. Twitter reported peaks exceeding 380,000 tweets per minute during major sporting events.

For capacity planning, this answer explicitly assumes a mature platform with 50 million registered users, 5 million concurrent viewers during a major match peak, 100,000 chat messages per second at goal-event spikes, and a 10x event multiplier for championship finals. Unless a number is tied to a citation, it is a stated design assumption.