Design a Live Sports Platform

Clarify the problem

The ask is to design a platform for watching live sport.

Viewers watch the match as it happens. They also follow the score and talk in live chat beside the video.

The platform streams live video of the match. It shows the current score. It carries the chat.

The score update must reach viewers in about 2 seconds. The video may lag the real action a little more, because a steady picture matters more than a few seconds of delay.

Recordings for later viewing are stored, but the live path is the hard part. Ticket sales and payments stay outside this design.

Estimate the scale

The event is one major final, and the peak is 50,000,000 viewers at the same time.

50,000,000 viewers × about 5 megabits per second each = 250 terabits per second of peak delivery.

The video load is steady once the match starts. Chat is the opposite. Chat is quiet for long stretches and violent at a goal.

At a goal, chat reaches 1,000,000 messages in a minute.

1,000,000 messages ÷ 60 seconds = about 16,667 messages per second.

Joins surge across the 10 minutes before kick-off too. 50,000,000 viewers ÷ 600 seconds = about 83,333 joins per second.

High-level design

Cameras at the stadium send one live feed to the platform.

An ingest service receives the feed. A queue holds the incoming video in order, so a brief stall never loses part of the match.

Workers transcode the feed into 5 renditions. A rendition is one copy of the video at one quality level.

The renditions sit in caches close to viewers. A CDN is a network of such caches spread across many places, and it serves nearly every viewer.

Each player uses adaptive bitrate. Adaptive bitrate means the player picks the rendition that fits its connection, and switches as the connection changes.

Two side paths run beside the video. A score service publishes score updates, and a chat service carries viewer messages.

Data model and APIs

Each operation is small, because the heavy data is the video itself.

A viewer opens a match page and requests the stream. The response lists the renditions on offer, and the player chooses one.

The score service offers one operation. A client subscribes to a match, and the service pushes each score update as it happens, inside the score budget.

The push rides a WebSocket. A WebSocket is a connection that stays open, so the server can send at any moment.

Chat offers two operations. A client sends a message to a match room, and the service delivers new messages to everyone in that room.

The stored records are small. A score record holds the match, the score and the time of the change. A chat message holds the room, the sender, the text and a sequence number.

Viewer counts are time-series data. Time-series data is a stream of measurements, each stamped with the time it was taken.

The platform samples the viewer count every 10 seconds. 3 hours × 3,600 seconds ÷ 10 seconds = 1,080 samples for one broadcast.

Downsampling keeps one sample per minute for the long-term record. 3 hours × 60 minutes = 180 samples kept per broadcast.

Deep dive on the goal moment

The test moment is a goal late in the final, when every load peaks in the same second.

Chat jumps to its peak at the goal. A queue takes each message first, so the spike lands on the queue instead of the workers behind it.

Fan-out stays small because the audience is split in advance. Viewers sit in chat rooms of 10,000.

50,000,000 viewers ÷ 10,000 viewers per room = 5,000 chat rooms.

A goal message fans out to one room, never to the whole audience at once. The celebrity problem has the same shape, and splitting the audience is the answer here.

Caches absorb the video spike in the same second. 250 terabits per second × 0.01 = 2.5 terabits per second reaches the origin when caches serve 99 of every 100 requests.

A waiting room guards the start of the match in the same spirit. It admits viewers in waves at 100,000 joins per second. 50,000,000 viewers ÷ 100,000 joins per second = 500 seconds of waiting for the last viewer.

A wait that long must be honest. The waiting room shows each viewer a place in line, and the wait buys a platform that stays up.

Evaluate the design

Steadiness under one shared spike is the test for this design.

Every part comes from the earlier courses, aimed at one shared spike. Nothing new had to be invented for the final.

The design trades delay for steadiness. A few seconds of video delay buy time to transcode, cache and switch renditions without stalling.

Under failure, the design sheds chat first. Graceful degradation keeps the video and the score running, and chat returns when capacity recovers.

If one cache location fails, its viewers fall back to a neighbour or to the origin. The origin is sized for the small share the caches miss, so a fallback is a strain, not a collapse.

The weakest point is the join surge. No cache can store a connection that does not exist yet, so the waiting room is the honest answer, and it is the first thing to test before a real final.

The design in numbers