Architect a voice-over-IP calling platform: scope, call flow, quality and scale

In a technical product manager interview, you are asked to design a voice-over-IP (VoIP) service: a product that lets people place and receive voice calls over the internet instead of over traditional phone lines. Decide who the service is for and what it must do at launch, then explain how it works end to end: how a call is set up and torn down, how the audio travels between the participants, how the service keeps calls sounding good, and how it holds up as call volume grows. Close with how you would judge whether the service is succeeding and the main risks you would plan for. ```hint Two very different kinds of traffic Setting up a call takes a handful of control messages, while the conversation itself is a nonstop stream of small audio packets that cannot wait. Reason about each kind of traffic separately: what it needs, where it should flow, and what happens when it is lost or delayed. ``` ### Clarifying Questions - Who is the customer: consumers using a calling app, businesses replacing their desk phones, or developers adding calling to their own software through an API? - Must the service call and receive ordinary phone numbers on the public telephone network, or only connect its own users to each other? - What is in scope at launch: one-to-one calls only, or also conference calls, recording, voicemail and automated phone menus? - Which countries must be served first? That decides which carriers, phone numbers and calling regulations apply. ### What a Strong Answer Covers - A chosen customer segment and launch scope, the use cases it serves, and what is deliberately left for later - An end-to-end call flow that separates call control from the audio stream and explains how devices behind home and office routers reach each other - Call-quality engineering: a latency budget, jitter and packet-loss handling, codec choice, and where media servers sit relative to users - Scale and reliability, with capacity estimates stated as assumptions, plus the connection to the phone network if it is in scope - Success metrics for quality, reliability and adoption, and the main risks such as toll fraud, emergency-calling rules and unwanted robocalls ### Follow-up Questions - Calls between users on two continents sound choppy. How would you find the cause, and what would you change? - When should audio flow directly between two devices, and when should it pass through your servers? - Fraudsters begin using stolen accounts to run up expensive international calls. How would you detect it and limit the damage?