Design WebRTC Platform

Problem Statement: WebRTC Platform as a Service

We are designing a WebRTC platform-as-a-service, the kind of infrastructure Twilio or Agora sells: other companies embed our SDK and get real-time audio, video, and data between their users without building the hard parts themselves. The fact that defines the architecture is that we are infrastructure, not a product. We do not own a meeting UI or a social graph; we own rooms, tracks, tokens, and the media path, and we expose them as APIs that thousands of customer apps call. Our reliability and our per-minute economics are the product.

The cleanest way to reason about it is a two-plane split. The control plane handles authentication, room orchestration, signaling (the exchange of SDP and ICE so two endpoints can find each other), and usage metering for billing. The media plane handles the actual packets: ICE and TURN for connectivity through NATs and firewalls, and an SFU (selective forwarding unit) that forwards media between participants without mixing. State this framing up front, because every later decision, from scaling to security to cost, lands cleanly on either the control plane or the media plane.