March 5, 2026
Comments Off on Why Autoscaling May Be Breaking Your RTC Calls (And How to Fix It)

Autoscaling is often treated as the gold standard for cloud efficiency. With a few lines of configuration, you can tune your infrastructure to match traffic in real-time, saving money while keeping your app solid under load. But with Real-Time Communication (RTC) apps, the rules change.

Whether you’re using WebRTC, SIP-based VoIP, or any other real-time media stack, traditional autoscaling can flip your system into the “Upside Down.” Instead of efficiency, you get dropped calls, ghost sessions, and frustrated users asking, “Can you hear me now?”

The root cause of RTC autoscaling challenges isn’t scaling itself, but that most autoscalers don’t understand that media is stateful in nature. Knowing why that matters, and how to design around it, is the key to scaling RTC infrastructure gracefully.

Stateless vs. Stateful Layers in RTC Autoscaling

RTC apps live in two worlds: the stateless web tier that scales like a dream, and the stateful media tier that fights every autoscaler.

The Stateless Layer: The Web Tier

This covers your API, your login page, and your signaling handshake. Servers here are interchangeable units. If your traffic spikes, you spin up ten more. If it drops, you remove five. Because no state is stored on the server, users never notice. A separate storage layer (databases, file storage, caches) keeps everything in sync.

The Stateful Layer: The Media Tier

This is where things get complicated. Media Servers (SFUs/MCUs) and TURN servers are not interchangeable. Once a video call starts, a sticky relationship is formed. Your audio and video packets are routed to a specific server that holds the context of that entire session.

Scaling this layer is difficult because you cannot simply move a live media stream to a different server without a massive glitch or a total disconnection.

Why Media Servers Have “Gravity”

In a standard web app, a load balancer can send your first request to Server A and your second to Server B. In RTC, media components have what we can call Resource Gravity.

If five people are in a virtual room, they generally all need to be on the same physical media server so that server can efficiently route video tracks between them. If your autoscaler decides to split those five people across different servers because of load balancing, your infrastructure must perform a massive amount of inter-node communication. This adds latency and it’s prone to breaking the call.

TURN servers face a similar dilemma. They relay traffic based on specific port and IP mappings created the moment the call connects. If that server disappears, the relay dies.

Comparison of two approaches for users to join a RTC session: participants joining to different servers vs participants joining the same server.

Why CPU Metrics Fail for RTC Media Servers

Most teams set scaling triggers based on good ‘ol CPU or Memory usage. While logical for web servers, media processing is extremely sensitive to micro-fluctuations.

By the time your average CPU hits 70%, your media threads might already be struggling with thread starvation. It’s like Star Trek’s Chief Engineer Scotty screaming that “the engines canna take anymore” yet the bridge display still shows everything in the green.

Instead of generic hardware metrics, you need to track Application-Level Metrics such as:

  • Active Sessions: How many rooms are currently live?
  • Active Participants: How many individual streams are we processing?
  • Packet Loss/Jitter: Is the quality actually degrading?

Find your Unit of Work. If your load testing reveals that one server can handle 200 participants safely, scale based on that count rather than waiting for RAM usage to spike.

The “Red Wedding” of Scale-In

The most dangerous moment for an RTC app is scaling in (removing servers when traffic is low).

Standard autoscaling services often look for underutilized nodes and terminate them to save costs. If that node is hosting a high-stakes board meeting, that call ends instantly. It’s the infrastructure equivalent of the “Red Wedding,” unexpected and brutal for the user experience.

To fix this, you need Custom Draining Logic:

  1. Cordon the Server: Mark it so no new calls can start there.
  2. Wait: Let existing calls finish naturally.
  3. Terminate: Only kill the instance when the active_sessions count hits zero.

If you can’t implement complex draining, consider Scheduled Scaling. Gradually scale down during known off-hours rather than reacting to a sudden dip in CPU.

RTC Service Discovery: Routing Participants to the Right Server

Your application needs to know exactly where every resource is and what it’s doing. This requires a service discovery mechanism.

Use a service registry (like Redis or AWS Cloud Map) that tracks:

  • Which media servers are currently “alive.”
  • Which Room_ID is living on which Server_IP.
  • The available headroom on each server.

When a new participant joins a room, your signaling logic should check the registry, see that the existing participants are on Server X, and route them there, even if Server Y is technically emptier.

Respect the Stream

The cloud was built for “cattle,” but media servers require the care of “pets.” If your scaling logic doesn’t understand your application logic, your users will pay the price in dropped connections.

Managing these complexities demands a deep understanding of both infrastructure and RTC protocols. If you want to ensure your platform scales smoothly without dropping calls during peak traffic, contact the experts at WebRTC.ventures to help you design and implement the right autoscaling strategy for your RTC application.

Further Reading:

Recent Blog Posts