CASE STUDY

911 Emergency Call Routing Platform

4 min read·708 words·Advanced

Asked at

1 candidate report in Oct 2025

How to use this case study

SDE-2 / Mid

Explain how a call is received, how the caller's location is found, and how it is routed to the right emergency center (PSAP).

SDE-3 / Senior

Go deeper on location sources (network, device GPS, registered address for VoIP), routing rules by geography, queueing and overflow, and callback on disconnect.

Staff / Principal

Discuss extreme availability (no single point of failure, geo-redundancy), surge handling during disasters, testing, and regulatory requirements.


0) Problem Restatement

Design a platform that lets people place emergency calls from mobile phones, landlines and internet (VoIP) phones and routes each call to the correct emergency response center, called a PSAP (Public Safety Answering Point). The key is getting the caller's location, both to route the call and to send help, and the system must essentially never be down. Salesforce asked this.


1) Requirements

  • Accept emergency calls (voice; optionally text-to-911).
  • Determine the caller's location as accurately and quickly as possible.
  • Route to the right PSAP based on location (county or city boundaries).
  • Show the dispatcher the caller's number, location, and history (e.g., previous calls).
  • Queue calls when all dispatchers are busy, and overflow to backup centers.
  • Callback if the call drops.

1.1 Non-Functional

  • Availability: effectively 99.999%+, with no single point of failure.
  • Low latency: connect within seconds.
  • Surge tolerance: disasters cause huge spikes (many callers about one event).
  • Accuracy and audit: every call recorded and logged.


2) Architecture

Architecture Diagram

flowchart LR
    CALLER["Mobile / landline / VoIP"] --> CARR["Carrier network"]
    CARR --> ESI["Emergency call gateway - geo-redundant"]
    ESI --> LOC["Location service"]
    LOC --> DB1[("Carrier cell / GPS location")]
    LOC --> DB2[("Registered addresses - VoIP")]
    ESI --> RT["Routing engine - geo boundaries"]
    RT --> P1["PSAP A - call queue"]
    RT --> P2["PSAP B - backup / overflow"]
    P1 --> D["Dispatcher console - map, caller info"]
    ESI --> REC[("Call records + audio")]

(In the US this is the "Next Generation 911" architecture: an emergency services IP network, location databases, and policy-based routing.)


3) Getting the Location

Several sources, from fastest to most precise:

  1. Carrier network location: the cell tower and sector (coarse, available immediately).
  2. Device-based location: phones send GPS/Wi-Fi location automatically during an emergency call (e.g., Android ELS, Apple's hybrid location), which is accurate to tens of meters.
  3. Landline: the phone number maps to a fixed service address in a database.
  4. VoIP: the user's registered address (must be kept up to date), plus the device location if available.
The routing engine uses the first good-enough location to route immediately (e.g., the cell sector → county), and the dispatcher receives updated, more precise locations as they arrive.


4) Routing

  • PSAP boundaries are stored as geographic polygons. Routing = find which polygon contains the caller's location (a point-in-polygon query with a spatial index).
  • Policy rules on top: time of day, PSAP status (closed, overloaded, evacuated), special numbers, language needs.
  • Overflow: if the primary PSAP's queue is too long or it's unreachable, route to the designated backup PSAP.
  • Transfers: a dispatcher can transfer the call (with all data) to another agency (fire, police, a neighboring county).


5) Availability and Surges

  • Geo-redundancy: at least two data centers in different regions, active-active. Each call can be handled by either, and carrier trunks connect to both.
  • No shared single points: redundant databases (location, boundaries) replicated to both sites. Routing works from local copies, so it still works if the network to the central DB fails.
  • Degraded mode: if location services fail, route by the carrier's default route for that cell tower and let dispatchers get the location verbally.
  • Surges: queue calls with a recorded message, overflow to partner PSAPs, and give dispatchers a way to see that many calls are about the same incident (clustered by location) so they can prioritize.
  • Callback: the caller's number is always captured first, so a dropped call can be called back.
  • Testing: regular failover drills, and monitoring with synthetic test calls.


6) Trade-offs & Alternatives

DecisionChoiceWhyAlternative
Routing locationFast coarse location first, refine laterConnect quicklyWait for GPS: delays
TopologyActive-active geo-redundant sitesSurvives site lossActive-passive: failover delay
Data accessLocal replicas of boundaries and addressesWorks during network failuresCentral lookup: single point of failure
OverloadQueues + backup PSAP overflowNo unanswered callsBusy signal: unacceptable

7) Wrap-Up

Receive emergency calls through geo-redundant, active-active gateways. Locate the caller using the fastest available source (cell sector, landline address, VoIP registration) and refine it with device GPS as it arrives. Route by point-in-polygon lookup against PSAP boundaries plus policy rules, with queues, overflow to backup centers, transfers and callbacks. Replicate all routing data locally, have a degraded mode for every dependency, and test failover regularly, because this system must never be down.

More Case Studies

Practice with a Mock Interview

Apply what you learned in a live system design mock interview with our AI interviewer.

Start System Design Interview →