Media & streaming, an interactive architecture walkthrough
Live streaming platform: how the architecture works
How a live streaming platform ingests one creator stream, transcodes it in real time, and serves short HLS segments to large audiences via a CDN.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A live streaming platform takes one video stream from a creator and delivers it to anywhere from a handful to hundreds of thousands of viewers with a delay of a few seconds. The creator's encoder sends a single high-quality stream over RTMP or SRT to a nearby ingest server, which authenticates the stream key and hands the video to a real-time transcoder that produces several resolutions.
A packager cuts each resolution into short segments and keeps an HLS playlist of the latest ones, an origin holds the live window, and a CDN serves segments to viewers, whose players switch quality as their bandwidth changes. Chat runs on a separate WebSocket path with moderation and a channel per stream, and viewer heartbeats drive viewer counts and analytics. This is a simplified learning design, not any company's production system.
Trade-offs and what changes at scale
Segment-based HTTP delivery scales through ordinary CDNs but adds seconds of delay; WebRTC delivery can get under a second but needs media servers for every viewer. Shorter segments reduce delay and increase request load. Transcoding every stream into a full ladder is expensive, so small channels may get only the source quality or a short ladder. At larger scale the cost is transcoding and CDN egress, and popular streams need the CDN to collapse simultaneous requests for each new segment.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
A creator copies a stream key from the Creator Dashboard, and Stream Key Auth ties that key to their channel. The key is a secret: anyone holding it can broadcast as that channel.
Broadcaster Software sends one high-quality stream over RTMP or SRT to the nearest of the Ingest Servers, which checks the key and registers the stream as live. Ingesting close to the creator reduces packet loss on the long upload path.
The Live Transcoder turns the source into a ladder of resolutions and bitrates in real time. Viewers on phones and slow networks need smaller renditions than the creator uploads.
The Packager cuts each rendition into two-second segments and updates an HLS playlist listing the latest ones. Short segments lower delay, but each one adds a request and some overhead.
New segments are written to the Origin and copied to the VOD / DVR Store, so viewers can rewind and the stream can be replayed later. The origin only needs to hold the last minute or so of each live stream.
A viewer's player asks the Playback API for the stream, which checks the Stream Registry and returns the playlist URL with an access token. Subscriber-only streams are enforced here.
The player fetches the playlist and segments from the CDN, which pulls each new segment from the origin once and serves it to everyone nearby. A stream with a hundred thousand viewers still causes only a few origin requests per segment.
The Viewer Player plays the segments through Media Source Extensions and switches rendition when bandwidth changes. Delay behind the creator is typically several seconds with standard HLS and a few seconds with low-latency HLS.
Chat runs separately over a WebSocket to the Chat Gateway, and each message is checked by Moderation before it is shown. Chat must feel instant even though the video is a few seconds behind.
Accepted messages are published on the stream's channel in Chat Channels and delivered by every chat gateway that has viewers of that stream. Very busy chats are sampled or slowed down, since no one can read thousands of messages a second.
Players send heartbeats to Stream Events, and the Viewer Counter counts concurrent viewers per stream from the last minute of heartbeats. Counting heartbeats, not connections, works because video viewers have no persistent connection.
A stream-started event makes the Notification Service tell followers the creator is live, and all events load into the Analytics Store. Notifications go out after the stream is actually playable, not when the key is first used.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (19 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Ingestdomain
- Ingest Servers: accept RTMP/SRT near the creator
- Stream Key Auth: validates key, starts session
- Stream Registry: live streams and their origin (redis)
Processingdomain
- Live Transcoder: 1080p, 720p, 480p, 160p ladders
- Origin: latest segments and playlists
- Packager: 2-second segments + playlists (HLS)
- VOD / DVR Store: segments for replay (s3)
Deliverydomain
- CDN: caches segments close to viewers
- Playback API: playlist URL, access token
- Viewer Player: HLS on MSE, adaptive bitrate
Interactiondomain
- Chat Channels: one channel per stream (redis)
- Chat Gateway: chat sockets per viewer (websocket)
- Moderation: filters messages, bans, slow mode
- Viewer Counter: concurrent viewers per stream
Datadomain
- Analytics Store: views, watch time, quality (clickhouse)
- Notification Service: "creator is live" alerts
- Stream Events: start, stop, viewer heartbeats (kafka)
Creatorslayer
- Broadcaster Software: OBS-style encoder, sends RTMP/SRT
- Creator Dashboard: stream key, title, moderation
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Video sharing platform (YouTube-style)How a video platform takes resumable uploads, encodes segments in parallel into several renditions, and serves them via a CDN with adaptive bitrate.
- Photo sharing platformHow a photo sharing platform takes uploads straight to object storage, resizes them in the background, and builds follower feeds from cached post ids.
- Content delivery networkHow a CDN routes users to a nearby PoP, serves cached copies, shields the origin with a regional tier, and purges content worldwide in seconds.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.