Design an Online Radio Service

Problem statement

Design an online radio platform that delivers continuously scheduled, linear audio channels to listeners in real time. Stations may be simulcasts of terrestrial AM/FM transmitters, internet-native curated channels, or live DJ shows with talk segments, ads, and music. The platform must ingest live audio from stations or DJs, transcode it into delivery formats, distribute it through an edge network, expose a real-time channel directory, track and display 'Now Playing' metadata, enforce region and licensing restrictions, and survive a station feed dropping without listeners noticing.

This is structurally different from on-demand streaming. In on-demand audio, the catalog is durable, every user requests a different byte range, and latency is irrelevant. In live radio, every listener of one station consumes the same timeline at roughly the same moment. The content is ephemeral: once a moment has aired, it is gone unless the platform deliberately recorded it. The product promise is the 'live' feeling: start-up in under a couple of seconds, and end-to-end latency low enough that callers, contests, breaking news, and sports commentary remain coherent with the outside world.

Why the problem is distinctive

Three properties drive the whole architecture. First, a single shared timeline per station means the workload is a fan-out problem, not a unicast library problem: one origin timeline, potentially hundreds of thousands of simultaneous consumers, served almost entirely from cache. Second, the stream is continuous and long-lived: there is no natural request boundary, so sessions, billing, ad insertion, and analytics must be constructed from heartbeats and segment boundaries rather than file fetches. Third, the upstream is unreliable by nature: a radio station's contribution link can die at any second, and the platform must fill dead air or fail over without corrupting the live timeline that thousands of players are following.

The design therefore separates the control plane (channel directory, sessions, metadata, entitlements, analytics) from the media plane (ingest, packaging, edge delivery). The media plane must tolerate control-plane degradation: a listener who cannot refresh the channel list can still keep playing the stream they have. The control plane must tolerate media-plane incidents: one station's encoder failing must not affect the other 2,499.

Public operating baseline versus design assumptions

Public evidence establishes that the category is real and large. iHeartMedia reports roughly 250 million registered users for its digital platform and tens of billions of listening minutes per year. TuneIn has publicly described more than 60 million monthly active users listening to live radio, sports, and podcasts. SiriusXM reports on the order of 34 million self-pay subscribers across its satellite and streaming products. The BBC operates dozens of live national and local radio services and has published research on low-latency DASH for live radio. These are company-reported figures used as context.

For capacity planning this answer explicitly assumes a mature platform with 2,500 live stations in the catalog, 8 million DAU, and 2.5 million concurrent listeners at peak. Unless a number is tied to a citation, it is a stated design assumption, target, or budget, not a claim about any company's private architecture.

The four architectural planes

1. Ingest plane: contribution links from stations and DJs (RTMP/SRT), monitoring, failover, and recording.
2. Packaging and delivery plane: transcoding, HLS/DASH packaging, origin shields, CDN live edge, and ad stitch points.
3. Control plane: channel directory, entitlements and geoblocking, session and QoE telemetry, Now Playing metadata, and notifications.
4. Operations plane: ingest health, stream QA, licensing evidence, incident response, and capacity management.

A strong answer keeps these planes separate. A station encoder crash is an ingest incident, not a control-plane outage. A metadata delay is a control-plane lag, not a reason for the audio to stop.