Design a Global One-to-One Voice Calling System

Design a global one-to-one voice-calling system for millions of registered mobile users. A user can call another registered user, the recipient receives an incoming-call notification, accepts or rejects, and accepted calls support real-time audio. ### Constraints & Assumptions - Distinguish account/device registration, call signaling, incoming-call delivery, and media transport. - Describe who sends each request, what identifiers and state it carries, and how the next step follows the response. - Clarify multi-device behavior and offline/background delivery; user count alone does not specify concurrent calls. - Keep user/device lifecycle responsibilities clear even if an early deployment co-locates services. ### Clarifying Questions to Ask - Can one user be signed in on multiple devices, and should all of them ring? - What is the policy for busy users, unanswered calls, and missed-call notifications? - Is peer-to-peer media acceptable, and what relay coverage is required for restricted networks? - Which identity and privacy checks govern caller information shown to the recipient? ### Part 1 — Registration and call setup Describe user/device records and the caller-to-recipient signaling sequence. #### What This Part Should Cover - When device IDs, push tokens, and user/profile data are stored and updated. - Authenticated create-call requests and incoming-call notifications. - The source of caller display information and checks against spoofed client fields. ### Part 2 — Accept, reject, and media Describe state transitions and how accepted participants establish an audio path. #### What This Part Should Cover - Call IDs, idempotent state transitions, competing accepts, timeouts, and cancellation. - Offer/answer and connectivity negotiation, with relay fallback. - Separation of signaling from real-time media and protection of media/session credentials. ### Part 3 — Global operation Explain how signaling and media resources scale and how the system handles disconnection. #### What This Part Should Cover - Regional routing, call ownership, active-connection state, and durable summaries. - Latency, packet loss, jitter, connectivity, and setup-success monitoring. - Reconnect and hang-up behavior without leaving inconsistent active-call state. ```hint Write one call as an event sequence Follow the caller, signaling service, push service, recipient device, and media path in order. A push notification wakes or alerts a device; it is not itself the authoritative call state. ``` ### What a Strong Answer Covers - A complete accepted and rejected call flow with explicit request/response responsibilities. - Clear service boundaries for registration, profile information, signaling, and media. - A globally operable design that handles mobile connectivity and state races. ### Follow-up Questions - What happens if two recipient devices accept the same call? - Why might registration and call setup share a deployment initially but still need separate logical ownership?