Architecting a Video Calling Backend That Scales at Minimum Cost

You are asked to design the backend that powers a video calling product, in which people talk over live audio and video from their own devices. After the core design, explain how the system grows with usage and how you would keep its cost as low as possible while it does. ### Clarifying Questions - Are calls mostly one-to-one, small groups or large meetings, and what is the largest call the system must support? - Which clients must work (browsers, mobile apps, desktop apps), and must calls hold up on weak mobile networks? - Are recording, screen sharing or joining by phone in scope, or only live audio and video? - How should cost be judged: infrastructure spend per participant-minute, total spend, or spend at a fixed bar for latency and call quality? ### Part 1 — Core architecture of a call Describe the main components needed to start a call and carry its audio and video between participants, including how media reaches devices that sit behind home routers and corporate firewalls. ```hint Separate the two flows Setting up a call and carrying its media have very different traffic patterns. Design the small, stateful control path apart from the high-bandwidth media path, then decide where media should flow for different call sizes. ``` #### What This Part Should Cover - Call setup and signaling, kept separate from the media path. - How media is routed for calls of different sizes, with the trade-offs between sending it directly between devices and routing it through servers. - Connecting devices across routers and firewalls, including the fallback when a direct connection fails. - Latency targets and how quality adapts to each participant's network. ### Part 2 — Scaling at the lowest cost Usage grows sharply. Explain how each component scales, where the money goes, and which design choices keep the cost per call minute low without making calls noticeably worse. ```hint Find the dominant cost first Estimate which resource grows fastest as calls get bigger and more frequent: server CPU, network egress or storage. Attack that one first, and check which savings users would actually notice. ``` #### What This Part Should Cover - A rough estimate of bandwidth and compute per call that identifies the main cost driver. - Techniques that cut media traffic and server work, and their effect on quality. - Capacity planning: autoscaling, regional placement and peak load such as many calls starting on the hour. - Containing failures so that losing one server does not drop many calls. ### What a Strong Answer Covers - Requirements and assumptions stated up front, with latency and quality targets that drive the design. - A design that chooses media routing by call size rather than one path for every call. - Cost reasoning grounded in rough numbers, with the cost-quality trade-off made explicit. - Reliability and observability: call setup success, media quality measures and graceful degradation. - Product-level calls a PM would own, such as which quality features to give up first under cost pressure. ### Follow-up Questions - A meeting grows to thousands of participants, most of whom only watch and listen. What changes in the architecture? - The monthly network bill comes in far above forecast. What would you check first, and what would you change? - How would you decide whether to offer end-to-end encryption, given that it limits what servers can do with the media?