At 9:58 on a Thursday, nobody at a 10,000-person company is in the all-hands. At 10:02, 8,000 of them are. Your video platform has to absorb that in four minutes, and steady-state capacity says almost nothing about whether it will.
Concurrent video session scale is usually discussed as a media problem: how many streams a server can forward. At org-wide peak, the media servers are rarely what fails first. What fails first is everything that happens when people join, because all of it happens in the same minute.
Two Peaks With the Same Headcount
Org-wide peaks come in two shapes. They put the same number of people on the platform and stress completely different things.
Shape A: the all-hands | Shape B: Monday 9:00 | |
|---|---|---|
What happens | One presenter, 8,000 viewers in one session | 2,000 four-person meetings start at once |
Joins | 8,000 in about four minutes | 8,000 in about four minutes |
Rooms | One | 2,000 |
Media pattern | One stream fanned out 8,000 times | Everyone sends one stream and receives three |
First pressure point | Can one session span enough servers? | Can you create and place 2,000 rooms fast enough? |
The scenario is illustrative: 10,000 employees, 80% attending the all-hands, and a Monday where 8,000 people are in small meetings. The arithmetic below scales linearly with your own numbers.
Shape A: One Room Bigger Than One Server
The all-hands is a broadcast, and the media numbers are large but predictable. LiveKit's published benchmarks are useful because they state the hardware: one 720p publisher to 3,000 subscribers ran a 16-core c2-standard-16 instance at 92% CPU, sending about 531 MB/s. That is roughly 1.42 Mbps per viewer.
At 8,000 viewers, the same rate is about 11.3 Gbps of egress, around 5,100 GB in an hour. Our guide to what that egress costs prices it by venue.
The harder constraint is structural. The same LiveKit page notes that in its benchmarks each room must fit within a single node, and 8,000 viewers is about 2.7 times what one benchmark node carried. An all-hands at that size needs a platform that can spread one session across several servers, which is the cascading covered in our post on consumers per core, network interfaces and cascading.
Hosted APIs make the limit explicit. Twilio's video quotas cap a room at 50 participants. An 8,000-person all-hands is not a bigger room on that kind of platform; it is a different product.
That leads to the honest counterweight: an all-hands may not need to be interactive at all. A one-way live stream with a few seconds of delay, plus chat or moderated Q&A, serves 8,000 viewers on ordinary streaming infrastructure. Real-time video earns its cost when viewers speak, not when they watch.
Shape B: Two Thousand Rooms in One Minute
Monday morning looks harmless room by room. Each meeting is four people, well inside any server. The total is not small: 2,000 rooms × 4 participants × 3 received streams is 24,000 forwarded streams, about 14.4 Gbps at a 600 kbps average. At the roughly 500 forwarded streams per CPU core the SFU scaling post works from, that is 48 cores of forwarding work, spread sensibly across hosts.
That much is ordinary capacity planning. The peak-specific part is creation and placement. Each room has to be created, assigned to a server and filled within a couple of minutes. If your backend creates rooms through a provider's REST API, the account limits apply: Twilio's default is 20 write requests per second, so creating 2,000 rooms takes 100 seconds before anyone is placed. Its default of 10,000 rooms in flight at once is fine here, but it's a number to check against your own Monday.
The placement logic matters too. Two thousand rooms arriving in a minute is the moment a scheduler that packs rooms onto the emptiest server makes its worst decisions, because "emptiest" is measured before the load arrives.
The Join Path Saturates First
Both shapes share the same expensive minute. Every join, in either shape, runs the same sequence:
Step | What it hits | Peak note |
|---|---|---|
Sign-in | Your identity provider | SSO sessions that expired overnight all renew at once |
Token request | Your token service | One request per participant, plus retries |
Signalling connect | WebSocket servers | Thousands of long-lived connections opening together |
Room lookup or creation | Your backend and the provider's API | Rate limits apply |
Connectivity checks | STUN and TURN servers | Up to 22% may need a relay allocation |
Media handshake | The SFU | Encryption setup costs CPU per connection |
If arrivals cluster, and for a meeting that starts on the hour they do, the rate is far above the average. Eight thousand joins over four minutes averages 33 per second. If half arrive in the final minute, it is about 67 per second. We know of no public data on arrival curves for scheduled meetings, so measure your own; the shape matters more than the total.
TURN is easy to forget. The only public measurement of relay share, callstats.io's 22% of conferences from 2015–16, is best read as a ceiling for SFU-based products, but even 22% of 8,000 is 1,760 relay allocations in four minutes.
The strongest evidence that the join path is its own failure domain comes from an outage. During Cloudflare's 12 June 2025 incident, its realtime SFU kept existing connections running but could not create new sessions, and its TURN service failed almost completely. Calls in progress survived; nobody new could join. At peak, that pattern is the whole event.
What to Do Before the Peak
- Load-test joins, not minutes. Most load tests hold a number of participants steady. Peak readiness means replaying a realistic arrival curve and measuring join success rate and time-to-first-frame.
- Pre-scale for scheduled events. The all-hands is on the calendar. Autoscaling that reacts to load starts adding servers after the storm has arrived.
- Pre-create rooms. For Monday-style peaks, create rooms when meetings are scheduled, not when the first person clicks join.
- Issue tokens early. A token sent with the meeting reminder at 9:55 moves load off the busiest minute, provided its lifetime covers the meeting.
- Size TURN for allocations, not just bandwidth. The allocation rate at peak is the number to test.
- Decide what the all-hands really is. If almost everyone only watches, a live stream is cheaper and more robust than an 8,000-person interactive room.
The Bottom Line
Concurrent video session scale at org-wide peak is a timing problem before it is a capacity problem. The all-hands needs one session to span several servers, Monday morning needs thousands of rooms created and placed in a minute, and both push every join through identity, tokens, signalling and TURN at once. Test the join path at the arrival rate you will actually see, and the media servers are usually the easy part.
What's Next
Peak is when an outage costs the most, and when the contract matters. Next: what a video SLA actually promises, and what the credit is worth when it breaks.
Frequently Asked Questions
How do you plan concurrent video session scale for an all-hands meeting?
Plan for the join rate as well as the audience. Eight thousand viewers need roughly 11 Gbps of egress at 720p and a platform that can spread one session across several servers, but the first stress is thousands of joins in a few minutes. If most attendees only watch, a one-way live stream is often the better tool.
What usually fails first when everyone joins a video call at once?
The join path: sign-in, token issuance, signalling, room creation and TURN allocation. Media servers are sized for steady state; the join path takes every request in the same minute. Outages have shown existing calls surviving while new joins fail.
How many participants can one video room hold?
It depends on the platform. Twilio caps a video room at 50 participants. LiveKit's benchmarks ran 3,000 subscribers on one 16-core node, with each room fitting on a single node. Larger sessions need cascading across servers or a broadcast path.
Does autoscaling handle video peaks?
Not by itself for scheduled peaks. Reactive autoscaling adds servers after load arrives, which is after the join storm. For known events, scale up in advance.
How should we load-test a video platform for peak?
Replay a realistic arrival curve, such as half the attendees joining in the final minute, and measure join success rate and time to first video frame, not just how many participants the system can hold once connected.
Does self-hosting change peak planning?
You own every step of the join path and the capacity behind it, including TURN. With a platform such as Samvyo, which supports on-premise and managed-cloud deployment and is based on SFU architecture, the questions are the same: how a large session spans servers, how fast rooms can be created, and how the join path was tested.
