// INSIGHTS
Broadcast-Grade Streaming for 5,000 Concurrent Viewers
5 min read
Five thousand concurrent viewers is an engineering number, not a marketing one. It decides your server topology, your bitrate ladder, your egress bill and how many things can fail before anyone notices. Our stack has been load-tested at 13.87 Gbit/s sustained, which is roughly 5,550 concurrent viewers at 2.5 Mbps. This is what that figure means in practice, where the ceiling really sits, and what changes above 2,000 viewers.
What 13.87 Gbit/s actually buys
Concurrency claims are meaningless without a bitrate attached. Five thousand viewers at 480p is a different machine from five thousand viewers at 1080p. We quote against 2.5 Mbps, which is a clean 720p or a conservative 1080p. It is also the bitrate most Indian viewers on 4G can genuinely sustain through a ninety-minute session.
At that bitrate, 13.87 Gbit/s of sustained egress works out to about 5,550 concurrent viewers. That is a tested figure, not a spec sheet extrapolation. The more useful number underneath it is per-server: each edge goes CPU-bound at roughly 3.5 Gbit/s, well before the network interface is anywhere near saturated. Transcoding and packaging burn cycles; the NIC is rarely the constraint.
That single fact determines the topology, which is three tiers:
- MAIN takes ingest from the venue and does the transcode work once.
- DIST fans that output out to the edges without re-encoding anything.
- EDGE serves viewers. Capacity is additive. Each edge adds roughly 1,400 viewers of headroom at 2.5 Mbps.
Scaling to 5,000 is therefore a question of how many edges you run and how early you bring them up. It is not a question of one very large server.
Tested capacity
How the topology holds
Transcode once, serve many
MAIN produces the bitrate ladder a single time. DIST and EDGE only move bytes. This keeps per-viewer cost flat as the audience grows.
Additive edge capacity
Every edge server adds about 1,400 viewers of headroom at 2.5 Mbps. Sizing an event becomes arithmetic instead of guesswork.
Redundant dual-path ingest
Two independent contribution paths from the venue with automatic failover. A dropped uplink does not become a dropped stream.
Clean encoder reconnects
A 25-second socket idle timeout means an encoder that loses internet reconnects properly instead of sitting in a half-open session that silently sends nothing.
Sizing a 5,000-viewer stream
Start from registrations, not hopes
Our planning assumption is peak concurrency near half of confirmed registrations for a free event, and closer to 80% when attendance is paid or mandatory. Then provision one edge above that.
Fix the bitrate ladder before the stage design
The ladder decides the bill. Include a 480p rung at the bottom for viewers on congested mobile networks, and cap the top rung honestly.
Pre-warm edges 45 minutes before doors
Bring capacity up before the audience arrives rather than reacting to load. Idle capacity for an hour is cheaper than buffering during the keynote.
Load-test the player page, not just the origin
Most failures at scale are in the registration wall, the API behind the player or the chat service. Test the whole page under synthetic load.
What usually goes wrong
Viewers do not arrive smoothly. They arrive in the ninety seconds after the calendar reminder fires. A 5,000-viewer event frequently opens 3,000 of those sessions inside two minutes. Auto-scaling that reacts to load is too slow for this shape of traffic. By the time a new edge is provisioned, healthy and warm, the spike has already produced buffering and a section of the audience has closed the tab. So we pre-warm instead of auto-scaling, and we accept paying for idle capacity around the join window.
The other half of the truth is that most reported stream problems at this scale are not on the server side at all. A viewer on congested 4G in a tier-3 town will buffer at 2.5 Mbps no matter how much egress sits behind the stream. Adaptive bitrate helps. A 480p rung helps more. But it means a real share of your audience watches a soft picture, and no amount of infrastructure changes that. Anyone promising broadcast quality to every viewer in India regardless of their connection is selling something. We would rather set the ladder honestly and keep the stream playing.
Common questions
Is 5,550 a hard limit?
No. It is the tested figure for the configuration we load-tested at 2.5 Mbps. Because each edge is CPU-bound at around 3.5 Gbit/s, capacity is additive: more edges, more viewers. Above that number the practical limits are budget and provisioning lead time, not architecture.
Do we need a commercial CDN on top of this?
Usually not at this scale. The MAIN to DIST to EDGE topology covers a single-country audience of a few thousand comfortably. A CDN starts to earn its cost when the audience is geographically scattered across continents or when you need very long-tail on-demand delivery.
What uptime do you commit to?
The platform runs at 99.95% on a rolling 30-day measure. For a single event that figure matters less than the failover design. Dual-path ingest, automatic failover and a 25-second socket idle timeout are what determine whether a two-minute internet outage at the venue becomes a two-minute outage for the audience.
Sizing a large stream
Tell us your expected registrations, target bitrate and venue, and we will come back with an edge count and a number in INR.
