Live streaming infrastructure is the chain of systems that carries a stream from camera to viewer: ingest, transcoding into a bitrate ladder, packaging, and delivery through a real-time media server or an HTTP content delivery network. At scale, two limits dominate: egress bandwidth, which grows with every concurrent viewer, and join spikes, which hit origins and signalling at once.
This guide is for developers and architects adding live video to a product that expects thousands of concurrent viewers. It gives you the stage map, the two delivery tiers, a worked egress calculation you can rerun with your own bitrate, where big events fail first, and what to ask a provider.
What live streaming infrastructure includes
Live streaming infrastructure splits into six stages, from ingest to Web Real-Time Communication (WebRTC) or HTTP Live Streaming (HLS) delivery, and each gives out in its own way as the audience grows. For segment and playlist mechanics, see how HLS segments and playlists work; for the transcoding stage, see encoding vs transcoding vs codecs.
| Stage | Job | Typical protocol or tool | What fails first at scale |
|---|---|---|---|
| Ingest | Receives the publisher's stream | RTMP (Real-Time Messaging Protocol), SRT (Secure Reliable Transport) or WHIP (WebRTC-HTTP Ingestion Protocol) | A single ingest path with no backup |
| Media server | Forwards every publisher's media | Selective forwarding unit (SFU) over WebRTC | Outbound bandwidth, per viewer |
| Transcode and package | Builds the bitrate ladder, cuts segments, writes playlists | H.264 encoder; HLS segments and M3U8 playlists | Compute, per stream |
| Origin | Serves the newest segments | HTTP server behind an origin shield | Misses when many edges ask at once |
| Edge delivery | Serves segments close to viewers | Content delivery network (CDN) | Egress bandwidth and cost |
| Signalling and chat | Joins, presence, chat, reactions | WebSocket or a pub/sub service | Connection storms at start time |
The reading that matters: three stages grow with the number of viewers, namely the media server on the WebRTC path, the edge on the HTTP path, and signalling and chat on both paths. Ingest, transcoding and packaging grow with the number of streams, and the origin with the number of edges asking for each segment. WHIP, published as RFC 9725 in March 2025, standardises WebRTC ingest into streaming services and CDNs.
The interactive tier costs server work for every viewer; the broadcast tier costs it once per segment per edge, and the edges carry the crowd.
Interactive and broadcast delivery: two tiers with different costs
Interactive and broadcast delivery are the two ways live streaming infrastructure reaches viewers, and their costs grow differently. The interactive tier uses WebRTC through a selective forwarding unit (SFU), a server that receives each publisher's media and forwards chosen streams to each receiver without mixing them; RFC 7667 calls this topology the Selective Forwarding Middlebox (section 3.7). Every viewer gets a separately forwarded stream, so SFU egress, and the number of servers, grows with each person who joins.
The broadcast tier sends HLS over ordinary HTTP. RFC 8216 states that HLS is compatible with large-scale HTTP caching infrastructure for large audiences: a segment is written once and the CDN serves the copies. The price is delay. RFC 8216 section 6.3.3 says a client should not start less than three target durations from the end of a live playlist, so viewers sit several segments behind the host.
The decision rule: put people who must talk, bid or react in real time on WebRTC, and everyone who only watches on HLS. Both tiers can run from one session, and that split is what makes scalable live streaming affordable, because the per-viewer path serves only the people who need it. For protocol trade-offs, read WebRTC vs HLS latency, scale and cost.
How much egress bandwidth does live streaming at scale need?
Egress bandwidth for live streaming at scale equals concurrent viewers multiplied by the average bitrate each viewer receives:
- Egress (bits per second) = concurrent viewers x average delivered bitrate
- Data per hour (bytes) = egress x 3,600 / 8
Worked example: Apple's HLS Authoring Specification gives 3,000 kbit/s as one of two H.264 bit rates for 1280 x 720 in its example ladder (the other is 4,500 kbit/s). One viewer at that rate for one hour receives 3,000,000 x 3,600 / 8 bytes, or 1.35 GB (decimal units).
| Concurrent viewers | Egress at 3,000 kbit/s | Data per hour |
|---|---|---|
| 1,000 | 3 Gbit/s | 1.35 TB |
| 10,000 | 30 Gbit/s | 13.5 TB |
| 100,000 | 300 Gbit/s | 135 TB |
| 1,000,000 | 3 Tbit/s | 1,350 TB |
Every tenfold jump in audience is a tenfold jump in egress. Your real average depends on your ladder and your viewers' networks, because RFC 8216 lets a receiver adapt the bitrate to network conditions. Apple's specification makes 2,000 kbit/s the default video variant, the first one listed in the playlist, and sets 730 kbit/s as the default for cellular delivery. If your viewers average 2,000 kbit/s, every row falls by a third. Adaptive bitrate streaming explains how players choose a rung.
The origin sees a far smaller number. In a simple model where an origin shield fetches each rendition once per segment, origin egress equals the sum of the ladder. Four of Apple's rungs, 6,000, 3,000, 2,000 and 365 kbit/s, total about 11.4 Mbit/s, for 1,000 viewers or 1,000,000. Without a shield, multiply by the edge locations pulling the stream: 50 edges draw about 568 Mbit/s. The WebRTC tier has no such split: for 1,000 viewers at 3,000 kbit/s, your SFUs send all 3 Gbit/s themselves.
Where high concurrency live streaming breaks first
High concurrency live streaming fails first at join time. Meta's engineering post How we scale Live streaming for millions of viewers simultaneously describes the pattern: a notification brings a spike of simultaneous viewers, edge caches without the content forward each request to the services behind them, and the resulting thundering herd causes lag and disconnection. Meta's defence was request coalescing and cache sharding.
Three places take that spike:
- The origin. Request coalescing turns identical misses into one upstream fetch, and an origin shield means the origin sees one request per segment instead of one per edge. See how CDNs cache and serve live streams for the edge side.
- Signalling and chat. Every viewer connects, authenticates and subscribes within the same minute, and one chat message to 50,000 viewers is 50,000 deliveries.
- The WebRTC tier. Each join needs a connection set up on an SFU, costing CPU and bandwidth at once.
In The Pragmatic Engineer's interview with JioCinema's former chief architect, about a stream that reached 32 million concurrent viewers in May 2023, auto-scaling is described as too slow for live events; the team scaled against a concurrency metric, and capacity planning can start a year ahead. The interview also names a lever: longer segments mean fewer requests per client, at the cost of viewers sitting further behind live.
Global delivery and reliability
Global delivery for live streaming infrastructure rests on three choices. Edge proximity: a CDN serves segments from caches near viewers, so origin distance matters only on the first request for each segment. Redundancy: Meta's post describes redundancy in transport, ingestion, processing, delivery and playback for its largest events; for a smaller team, that starts with a second ingest path and a standby encoder. Access control: signed playback URLs and short-lived tokens make it harder to pass a paid stream around, and the edge has to check them.
What to ask a provider before a high-concurrency event
A provider for a high-concurrency event is judged on documented limits, not headline numbers. Get each answer as a link to a documentation or pricing page:
- Are concurrency limits per organisation, per room, or both?
- How are limits raised, how far, and with how much notice?
- What is the price per viewer-minute on each tier, and are encoding minutes billed separately? Date every answer.
- What latency does each tier deliver, and which page states it?
- What uptime service level agreement (SLA) applies to your plan?
- Which ingest protocols are documented: RTMP, SRT, WHIP?
- Which regions process and deliver media?
How VideoSDK maps to this architecture
VideoSDK's interactive live streaming docs structure a stream in the same two tiers.
- Interactive tier: interactive live streaming (ILS) puts hosts in a room in
SEND_AND_RECVmode and the audience in the same room inRECV_ONLYmode. - Broadcast tier:
startHlsturns a joined room into an HLS stream with a playback URL. The HLS docs describe two setups: presenters in the room while viewers only watch the stream, or viewers who also join the room with their own role for polls and discussion. - Ingest: WHIP brings an external WebRTC encoder, such as OBS, into a room as a participant. RTMP ingest and SRT ingest are not documented as of 1 Oct 2026; RTMP is output only, pushing the room to platforms such as YouTube.
- Limits: the quotas page sets concurrency per organisation, which monthly add-on packs raise, and separate default per-room limits of 15 active speakers, 100 participants, 1,000 Interactive Live Streaming viewers and 200 HTTP Live Streaming viewers. The page does not say whether add-on packs raise the per-room limits; Enterprise limits are set per customer.
- Cost, as of 1 Oct 2026: /pricing bills ILS and HLS separately. ILS viewers at 720p cost $0.002 per viewer minute, so 1,000 viewers for one hour cost $120. HLS charges $0.001 per viewer minute at 720p, per the docs pricing FAQ, plus $0.04 per livestream minute of 720p encoding, so the same hour costs $60 in viewer minutes plus $2.40 of encoding whatever the audience size.
Glossary
Selective forwarding unit (SFU): A media server that forwards each publisher's stream to receivers without mixing or re-encoding it.
Bitrate ladder (ABR ladder): The renditions one stream is encoded into, so each adaptive bitrate (ABR) player can pick one its network sustains.
Origin shield: A cache tier between the origin and CDN edges, so the origin serves each segment about once.
Request coalescing: Answering many identical cache misses with one upstream fetch.
WHIP (WebRTC-HTTP Ingestion Protocol): The IETF Standards Track protocol, RFC 9725, that uses an HTTP exchange to set up a WebRTC session for sending media into a streaming service or CDN.
Key takeaways
- Live streaming infrastructure has six stages; media bandwidth grows with the audience only at the SFU on the WebRTC tier and the CDN edge on the HLS tier, while signalling and chat grow with every viewer on both.
- Put people who must interact on WebRTC and watch-only viewers on HLS, so the per-viewer tier stays small.
- Size egress as concurrent viewers x average delivered bitrate: 1,000 viewers at 3,000 kbit/s need 3 Gbit/s and 1.35 TB per hour.
- Plan for the join spike: shield the origin, coalesce requests, and load-test signalling and chat at full audience.
- Get every provider limit, price and latency figure as a dated link, per organisation and per room.
Next, run the egress formula with your own ladder and audience, and hold the result against your provider's quotas. To build the two-tier pattern, start with the VideoSDK HLS docs and a $20 credit on a new account.
Frequently asked questions
What is live streaming infrastructure?
Live streaming infrastructure is the set of servers, networks and protocols that move a live stream from a publisher to its viewers. It covers ingest, a media server, transcoding and packaging, an origin, CDN edges, and a signalling layer for joins and chat. Each stage scales on a different variable: streams, segments or viewers.
What should you look for in a live streaming provider for high-concurrency events?
Look for a quotas page with organisation and per-room concurrency, dated per-viewer-minute prices by tier, and a stated lead time for raising limits. Then run a load test at your expected peak that includes the first minute of joins, and confirm who you contact if a limit is hit mid-stream.
Can WebRTC deliver a live stream to thousands of viewers?
Yes, through selective forwarding units, but server egress grows with every viewer because each receives a separately forwarded stream: 10,000 viewers at 2,000 kbit/s means 20 Gbit/s leaving your media servers. Large audiences need several SFUs linked together, called cascading, or a split where only participants stay on WebRTC and watch-only viewers move to HLS.