The scaling question a video API answers is not "how many can join a room" but "how does the room behave as that number grows."
The shape that scales — and the one that doesn't
Rooms come in three shapes, each with a different scaling profile:
- 1:1 — two publishers, peer-like, trivial bandwidth. Any video API scales here; the contest is over embed, recording, and moderation, not topology. The next vendor answer to a 1:1 support call is always yes.
- Small-group (2–12) — the moderate shape, where the SFU (selective forwarding unit) already earns its keep: every publisher streams once, the SFU forwards the published tracks to every subscriber. Publish-only and receive-only joins both work; participant caps become an operator choice, not a physics problem.
- Broadcast (12+ to thousands) — the shape where the room stops being a mesh and starts being a one-to-many stream. The limiting factor is subscriber bandwidth — each viewer receives the forwarded video, and the room's publish side is bounded by the hosts.
Devotel Orbit ships one room model across all three shapes: moderated, in-browser, with a waiting room minted into the join token. The dedicated RTC vendors ship the same topology — Agora, LiveKit, Daily, 100ms — which is why the honest-parity story the video and RTC provider comparison leads with is parity on the video-room core and on live broadcast.
Publish vs subscribe — the grant decision
The physical limit a scaling room hits is not the SFU's CPU but the room's own mix of publishers and subscribers. Each publisher uploads a stream the SFU must forward to every subscriber; the subscriber count times the forwarded bit-rate is the load. The operator's scaling decision is therefore about who may publish:
- Grant tiering. Viewers join as receive-only subscribers; panelists and hosts publish. Orbit's grant tiers — viewer, panelist, host, and the hidden supervisor tier the moderation surface uses — are minted into the join token the moderation and waiting-room checklist covers.
- Broadcast topology. A webinar or audience session runs with a handful of publishers and an arbitrary number of viewers. The scaling ceiling on the broadcast shape is therefore the subscriber count, which grows linearly while the publish side stays constant.
Where avatar participants and recording fit
Two capabilities change the publish-side accounting:
- An AI video avatar participant joins as a publish-capable bot — it counts as a publisher against the room's upstream, and it needs the same grant-tier discipline as a human panelist (it cannot accidentally broadcast to a subscriber whose grant is a viewer when the program intends a hosted walkthrough).
- Session recording, co-browse, and moderation run the same way at any room size; the capture is a per-session, per-track metered event on the account, not a topological constraint. The pricing-models post works through how each of those events bills across the three model shapes.
The honest parity question
A buyer cutting the dedicated RTC vendor list down to Orbit is not trading away scale — the video-room core and live broadcast shape both ship parity, as the comparison matrix frames it. The real differences live around the room, not inside it: one account for video plus messaging, email, voice, and the AI agents (one pay-as-you-go bill instead of a vendor stack), and the shipped video differentiators the dedicated RTC APIs do not publicly document (in-call co-browse, revocable-recording links, avatar participants). Program-scaling does not close with a topology argument against Orbit; it closes with the account and features around the room.
How to plan a scaling program
Run room capacity as a checklist, not a ceiling:
| Program shape | What the plan names |
|---|---|
| 1:1 support consultation | Embed surface, token-minted lobby, moderation controls, recording eligibility |
| Small panel webinar (2–12 publishers) | Grant tiers for speakers, hidden supervisor for moderation, broadcast view-only for the audience |
| Large broadcast (12+ to thousands) | Publish-side kept to hosts/panelists, subscriber count as the scaling variable, tiering configured as viewer |
The RTC/video evaluation guide carries the full criteria battery; the Orbit vs Agora, Orbit vs LiveKit, Orbit vs Daily, and Orbit vs 100ms head-to-heads score the vendor field.
Frequently asked questions
Does Orbit support the three room shapes on one account?
Yes — 1:1 support, small-group panel, and broadcast audiences run on the same moderated room model, with the grant tier (viewer / panelist / host / supervisor) minted into the join token. The program picks the shape per session; the account does not enforce one shape.
What limits the scaling of a broadcast room?
The subscriber count, gated by bandwidth: every viewer receives the forwarded streams the small number of publishers upload. Because the publish side is bounded by the hosts, the scale question resolves to the receive side — fixed upstream, variable downstream — which is what the one-to-many broadcast topology ships for.
Is topology the deciding feature when comparing video APIs?
At the video-room core and the broadcast shape, the dedicated RTC vendors and Orbit ship parity; topology is not the deciding feature. The deciding features are the account around the room (one vendor bill, shared usage statements) and the video differentiators shipped on the room (co-browse, recording revocability, AI avatar participants).
Published 21 September 2026.