How do I scale video calling for a large user base?

Scaling video calling for a large user base is mostly a real-time media architecture problem. The best approach depends on your use case: one-to-one calls, small group calls, or large live broadcasts. Here’s a practical way to think about it.

1) Pick the right media model

A. P2P for 1:1 calls

• Best for simple one-to-one calls.
• Lowest infrastructure cost.
• Uses WebRTC directly between clients.
• Still usually needs a signaling server and STUN/TURN.

Limitations: NAT/firewall issues, hard to scale for group calls, less control over quality.

B. SFU for group calls

• Best for most modern video apps with 3+ participants.
• Clients send one upstream video/audio stream to an SFU (Selective Forwarding Unit).
• SFU forwards streams to other participants without heavy re-encoding.

Why it scales well:

• Much lower CPU cost than mixing/transcoding.
• Each client uploads once instead of to every participant.
• Good for dynamic layouts, speaker view, large meetings.

Common choice: This is usually the best architecture for “large user base” video calling.

C. MCU for fully mixed rooms

• Server receives streams, decodes, mixes, and re-encodes a single composite stream.
• Easier for very low-end clients or broadcast-style rooms.

Tradeoff: High server CPU/GPU cost and less flexibility.

---

2) Use WebRTC as the transport layer

For browser/mobile calling, WebRTC is the standard. You’ll need:

• Signaling: exchange SDP/ICE, room membership, call state
• STUN/TURN: NAT traversal
• Media servers: SFU/MCU depending on use case

Popular SFU options:

• mediasoup
• Janus
• Jitsi
• LiveKit
• Pion-based custom SFU
• Twilio / Agora / Vonage if you want managed infrastructure

---

3) Architecture for scale

A common scalable setup:

1. Client app

   • Captures audio/video
   • Connects via WebRTC
   • Adapts bitrate/resolution based on network

2. Signaling service

   • Room creation
   • User presence
   • Call negotiation
   • Auth/session control

3. SFU layer

   • Forwards streams
   • Manages subscriptions
   • Simulcast/SVC routing
   • Possibly geo-distributed

4. TURN/STUN infrastructure

   • TURN relays for restrictive networks
   • Keep TURN capacity sized for worst-case fallback

5. Control plane

   • Load balancing
   • Room placement
   • Autoscaling
   • Failure recovery
   • Metrics and orchestration

---

4) Scale by region and room placement

Don’t send all users to one central cluster.

Best practices:

• Place users on the nearest region geographically.
• Keep a room on one SFU node/cluster when possible.
• For very large rooms or global audiences, use:
  • region-based SFUs
  • cascading SFUs
  • edge nodes + backbone relay

Goal:

Minimize latency, packet loss, and cross-region bandwidth costs.

---

5) Use adaptive streaming techniques

To support many users on varying networks:

• Simulcast: send multiple quality layers from sender
• SVC: scalable video coding with layers
• Adaptive bitrate: reduce quality when bandwidth drops
• Dynamic subscription: only receive visible/speaking participants
• Active speaker detection
• Thumbnail vs. speaker stream separation

This is critical to scale bandwidth efficiently.

---

6) Reduce bandwidth and compute costs

On the client:

• Default to lower resolution for many-participant rooms
• Pause video for inactive users
• Only send video when needed
• Use efficient codecs:
  • VP8/VP9
  • H.264 for broad compatibility
  • AV1 if supported and cost justified

On the server:

• Prefer SFU over transcoding
• Avoid unnecessary recording/transcoding in the live path
• Offload recording to separate pipelines
• Use hardware acceleration only where it clearly helps

---

7) Make TURN a fallback, not the default

TURN relay traffic is expensive because it proxies media.

Use:

• STUN first
• TURN only when direct peer/SFU connectivity fails

Operationally:

• Monitor TURN usage closely
• Scale TURN separately
• Expect some percentage of traffic to require relay

---

8) Design for failures

Video systems must degrade gracefully.

Handle:

• node crashes
• packet loss
• region outages
• reconnections
• participant churn

Strategies:

• health checks
• quick room failover
• reconnect logic on clients
• session resumption
• state replication for signaling
• idempotent join/leave events

---

9) Observe the right metrics

You cannot scale video without strong observability.

Track:

• join success rate
• call setup time
• packet loss
• jitter
• RTT
• freeze count
• audio/video bitrate
• TURN usage
• SFU CPU, memory, NIC, and per-room fanout
• reconnect rates
• MOS/quality scores if available

These metrics tell you where bottlenecks are.

---

10) Plan for your specific call type

1:1 consumer calling

• P2P + TURN fallback
• lightweight signaling
• small number of regions

Small group meetings

• SFU
• simulcast
• active speaker switching
• regional placement

Large webinars / live classes

• SFU or broadcast pipeline
• maybe one-way video for audience
• separate chat/Q&A path
• viewer-centric optimization

Massive live streaming

• not truly “video calling”
• use CDN-based streaming instead of interactive WebRTC where possible

---

11) Managed vs self-hosted

Managed platform

Pros:

• faster time to market
• easier global scaling
• less operational burden

Cons:

• vendor lock-in
• cost at scale
• less control

Self-hosted

Pros:

• more control
• potential cost benefits at high scale
• custom optimization

Cons:

• difficult operations
• more engineering effort
• need real-time infra expertise

---

12) Practical recommendation

If you’re starting from scratch:

1. Use WebRTC
2. Use an SFU architecture
3. Implement strong signaling + auth
4. Add STUN/TURN
5. Use simulcast/adaptive bitrate
6. Deploy in multiple regions
7. Build metrics and autoscaling
8. Keep recording/transcoding off the hot path

---

A simple rule of thumb

• 1:1 calls: P2P
• 2–20 users: SFU
• 20+ users in a room: SFU with selective subscriptions
• Huge audience: broadcast architecture, not classic group calling

If you want, I can also give you:

1. a reference architecture diagram,
2. a technology stack recommendation, or
3. a cost model for scaling to 10k / 100k concurrent users.