Designing a Calling App

What you'll learn

• Problem Statement

  Design a calling application that supports both VoIP (Voice over IP) and PSTN (Public Switched Telephone Network) calls. The system must handle call routing, real-time state management, billing, provider selection, and scale to millions…

• Requirements

• Functional Requirements

  - Users can make calls over VoIP (internet-based) or PSTN (traditional telephony) - Call routing between users regardless of their connection type - Balance management and call charging (per-minute billing) - Provider selection per call…

• Non-Functional Requirements

  - Low latency ( The important split at this stage: signaling is stateless and horizontally cheap, media bridging is stateful and expensive. A SIP pod can die mid-INVITE and the retry lands on another pod. A Switch Box dying mid-call drop…

• Stage 3 — Bottleneck: Real-time call state consistency across Switch Boxes

  This is the first genuinely hard problem in a calling app. When User A on Switch Box 3 calls User B on Switch Box 7, four independent facts must stay in sync in real time: - A's session is bound to Switch Box 3. - B's session is bound to…

• Stage 5 — Mature architecture

  Here's what the system looks like once Stages 2–4 land. The control plane and media plane are cleanly separated; the log is the source of truth for state; consumers scale independently. Node count is deliberately kept in the low double d…

• Cost vs Complexity — When to Pick What

  A rough summary of what each tier of the system looks like at MVP, growth (10k–100k concurrent), and enterprise (millions of concurrent, globally distributed): | Concern | MVP choice | Growth choice | Enterprise choice | |---------|-----…

• Migration Path (MVP → Enterprise)

  The order matters. Some steps unblock others; some are safe to defer for years. Rough dependency order: 1. Split media from signaling (Stage 2). Move the Switch into its own process and address it by ID. This is the single most valuable…

• Architecture Diagram

  ---

• Key Design Decisions

  1. Switch is dumb — It only bridges connections and emits events. All intelligence lives in consumers. This makes the Switch simple, fast, and reliable. 2. Event-driven over synchronous — State changes flow through MQ, allowing services…