Problem RestatementProblem
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.
RequirementsRequirements
- 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.
ArchitectureArchitecture
%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
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.)
Deep Dive — Knowing where the caller isDeep dive
The whole system exists to get responders to a location. The caller may be unable to say where they are, so the location has to come from the network, and different call types give it with wildly different precision.
Use the registered address
Look up the account's billing or service address and route on that.
%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart LR
CALL["Emergency call"] --> ACC["Account address on file"]
ACC --> LAND["Landline - correct"]
ACC --> MOB["Mobile - the caller is 400 km away"]
ACC --> VOIP["VoIP - address never updated after moving"]
MOB --> WRONG["Call routed to the wrong emergency centre"]
WRONG --> DELAY["Transfer, re-questioning, minutes lost"]It is right for the one call type that cannot move and wrong for the two that can. A misrouted emergency call is not just slow — it arrives at a centre with no authority to dispatch in that area, so the whole interaction restarts.
Use the carrier's network location
Take the cell tower and sector, which the network knows as soon as the call connects.
This routes correctly, and it is available immediately — which is the property that matters, because routing must happen before anyone speaks. Its precision is the problem: a sector can cover hundreds of metres in a city and kilometres in the countryside. It is enough to pick the right centre and not enough to find the caller.
Route on what is available now, refine continuously
Separate the two questions, because they have different deadlines:
%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart LR
T0["Call connects"] --> COARSE["Cell sector / registered address - available instantly"]
COARSE --> ROUTE["Route to the correct centre - decision made now"]
T1["Seconds later"] --> DEV["Device location - GPS / Wi-Fi, tens of metres"]
DEV --> PUSH["Pushed to the dispatcher mid-call"]
PUSH --> MAP["Dispatcher's map updates while they are still talking"]
DEV --> BETTER["Later, better fixes keep arriving"]
BETTER --> PUSH- Route on the first good-enough location. Waiting for a precise fix delays the routing decision, and routing only needs to be accurate to a jurisdiction. Precision can arrive afterwards.
- Device-based location is the accurate source — modern handsets send a GPS/Wi-Fi hybrid fix automatically during an emergency call, accurate to tens of metres — but it takes seconds and may never arrive indoors.
- Keep updating the dispatcher. The location is a stream, not a field. Each better fix is pushed mid-call, so the map sharpens while the call is still in progress.
VoIP is the awkward case worth raising: there is no network location at all, so it depends on a registered address the user must keep current, supplemented by device location when the app can provide it. That is a known structural weakness of VoIP emergency calling rather than something this design fixes.
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).
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.
Trade-offs & AlternativesTrade-offs
| Decision | Choice | Why | Alternative |
|---|---|---|---|
| Routing location | Fast coarse location first, refine later | Connect quickly | Wait for GPS: delays |
| Topology | Active-active geo-redundant sites | Survives site loss | Active-passive: failover delay |
| Data access | Local replicas of boundaries and addresses | Works during network failures | Central lookup: single point of failure |
| Overload | Queues + backup PSAP overflow | No unanswered calls | Busy signal: unacceptable |
Wrap-UpWrap-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.