Live Sports Streaming at Scale

The service covers sports internationally through articles, real-time commentary, live streaming, and more. For scale context: Cricbuzz sees ~220M monthly visitors; Hotstar handles ~420M users with 10–25M concurrent during peak cricket season.

The design trick is that the homepage isn't one application — each section is powered by a separate backend service, and each is itself a full-blown distributed system. Build them independently, then club them together via APIs and message queues:

Picture the FIFA final, England vs. France, with two traffic hotspots. Raw high-resolution video is enormous — it exhausts bandwidth, burns compute and storage, and pushes latency up. The whole first-mile pipeline exists to shrink that latency.

1. Encoding — compress the file size without hurting quality, using codecs like H.264 (AVC), H.265 (HEVC), H.266 (VVC), AV1, VP9, MPEG-2. [+] Newer codecs trade more CPU for smaller files. (YouTube engineering famously moved to VP9.)
2. Transcoding — re-encode into multiple formats, resolutions, and aspect ratios so the stream plays on any device under any network. The stream should never stop; quality may drop, but playback continues.
3. Segmentation — split the stream into 1–6 second chunks so the client plays the first segment immediately instead of waiting for a whole file.
4. Decoding — the client's player uncompresses each segment and plays it.

Adaptive bitrate streaming

Bitrate is data-per-unit-time (Mbps); higher bitrate = higher quality. Transcoding produces the same stream at several bitrates, and the client's adaptive bitrate algorithm switches between them at segment boundaries based on current bandwidth. Weak network → next segment comes in at a lower bitrate; the stream keeps rolling.

Protocols & knowing your audience

Multiple protocols cover different legs: RTMP for the first mile (camera → encoder) and often the last mile; HLS or MPEG-DASH for delivery to devices; SRT is another transport option. When designing, know the audience: typical bandwidth, rural vs. urban infrastructure, mobile vs. Smart TV, and content type (a 2D cartoon compresses far more cheaply than a live match).

The backend does far more than encode — it stitches ads, embeds live scores/graphics, adds the broadcaster logo, restreams to YouTube/Facebook, runs real-time monitoring, and stores the stream for later. Once packaged, the stream is pushed from the origin data center to edge locations worldwide, nearest to each viewer. Edge nodes act as caches: fetch from origin once, serve many nearby viewers, minimizing latency and origin load.

The fix is request coalescing: requests are never let through to origin. The edge node queues all requests for a missing segment, fetches from origin once, populates the cache, and fans the single response out to every waiting viewer.

Once the stream is live, you need a system that continuously confirms it renders well on viewers' devices, watches for errors, and alerts on-call staff instantly. Viewer devices emit video playback logs into an ELK stack:

Log management is just one ELK use case — it's also used for app metrics, performance, endpoint security, uptime, and application search.

Archiving old data — and why tape still matters [+]

Keep recent data (≤ ~1 year) in Elasticsearch; archive older data to cloud archival storage, which cuts cost dramatically and frees space, while still serving archived data via API in milliseconds (no tape-style retrieval delay). But cloud storage isn't a 100% replacement for tape — software bugs can inadvertently delete data. Two real Google incidents make the case:

The takeaway: combine cloud archival and tape backups for critical data. (Source: Google Research, Designing and Operating Highly Available Software Systems at Scale.)

Why not push logs straight to Logstash? During a live event the log influx is massive, and Logstash's filtering/transforming plus Elasticsearch's indexing all take time. Under that velocity, the pipeline bottlenecks. Kafka is placed in front of Logstash as a buffer — Logstash consumes from Kafka topics at its own pace, exactly like the edge cache absorbing the thundering herd.

Kafka fundamentals

• Producers, consumers, topics. Producers write events to a topic; consumers subscribe and pull. Many producers/consumers can share a topic (e.g. topic android logs for all Android-device logs). Producers and consumers are decoupled — neither waits on the other.
• Push or pull. Producers push to topics; consumers pull. Pull lets each consumer read at its own processing speed without being overwhelmed.
• Broker & cluster. A broker (= node = server) runs one Kafka process; a cluster has multiple brokers (min 3).
• Partitioning. A topic splits into partitions across brokers for parallelism. Events append to a partition by key, and Kafka guarantees order within a partition.
• Replication. Topics are replicated across availability zones/regions; a typical production replication factor is 3.
• Extras. Kafka Connect imports/exports from other systems; Kafka Streams processes streams. Deployable on bare metal, VMs, containers, on-prem, across regions.

Because Kafka is highly available, fault-tolerant, and O(1) with respect to data size, it can durably store events for as long as you want — like a distributed database that also streams.

Counterintuitively, Kafka relies on disk + the filesystem rather than in-memory caching. Disks are slow or fast depending on how you use them — a well-designed disk structure can be as performant as you need. Four techniques do the heavy lifting:

For replays, highlights, and key moments, persist the live stream to cloud object storage (how YouTube stores video). The critical design point:

A file's disk path might be https://livestream.ourwebsite.com/football/engvsfrance_fifa_20220417.mp4. The host part goes into a config/property file; the path part (/football/engvsfrance_fifa_20220417.mp4) goes into the MySQL LiveStream table. You can even factor /football into config and assemble the full path at fetch time — it depends on the use case.

Storage estimation for one game [+]

A 2-hour match at ultra-HD 8K compresses to ~28 GB. Transcoding into lower ladders adds up:

Rough numbers — actual size varies with bitrate, bit depth, codec, resolution, and frame rate (size references from Netflix). Cloud storage cost depends on data size, instance types, number of operations, bandwidth, cross-region replication, daily backups, and storage class.

These practices apply to any distributed service, not just streaming. Step one is deep visibility with no blind spots — every module monitored.

• Observability vs. monitoring. Observability is a property of the system (how observable is it?); monitoring is what you do to achieve it.
• Telemetry = metrics + logs + traces. Metrics are numeric state over time (CPU %, uptime); logs go with the code and are checked first when something breaks; traces follow a request across services.
• Distributed tracing. Each request gets a unique trace ID; every operation (a span) carries that ID plus its own id and context — invaluable in multi-service architectures. Popular tools: Zipkin, Jaeger.

Synthetic traffic, then chaos

Before the real load hits, send synthetic traffic from different cloud regions to test availability, performance, and transaction flows (login, subscription) under artificial peak load — surfacing bottlenecks and regional errors early.

Capacity planning & ladder-based scaling

Estimate average and peak game-day traffic from past game data and load tests. Then here's the key warning: don't rely on autoscaling for sudden spikes. New instances need provisioning, warm-up, and cluster registration — minutes you don't have when traffic climbs by millions of hits per minute. Worse, the cloud may not have the instance types you need in that region right then.

Instead use ladder-based scaling with pre-provisioned buffers:

50K–100K hits/min   →  x instances running (even if underutilized)
100K–150K hits/min  →  x + 20 instances
150K–300K hits/min  →  x + 40 instances
...as traffic climbs the ladder, pre-defined instances spring to life

A ready buffer means no warm-up wait. Even so, there's a financial ceiling on instances/clusters — so two more levers matter.

Graceful degradation

Services have priorities. During the event, streaming, sign-in, and subscription payment are high-priority; movie recommendations, feedback, and search are not. Under exceptional load, reallocate resources from non-priority services to priority ones — the low-priority services still respond, just more slowly. That's graceful degradation.

Throttling & rate limiting

Throttling controls the rate of events to keep servers from being overwhelmed. Applied on the backend to an API it's called rate limiting — it caps requests per time window, adds a security layer against bots/scraping/DDoS, and underpins SaaS request-based pricing. Algorithms: token bucket, leaky bucket, fixed window counter, sliding window, sliding window counter.

The links below all resolve live, grouped by topic. The author's own course cross-links and one source that failed to load (a scaleyourapp.com blog on 100M-user scale) are omitted.

Streaming & codecs

Observability & the ELK stack

Kafka performance

Reliability, chaos & storage