Design a Disaster Alert & Communication System

Medium45 min
1 / 30
System design answer

Design a Disaster Alert & Communication System

Medium45 min30 sections
understanding•10 min read

Problem Statement: A Life-Saving Geo-Targeted Fanout Engine

Frames the disaster alert system as a reliability-first, geo-targeted multi-channel fanout engine rather than a generic notification service.

Problem statement

Design a Disaster Alert & Communication System that lets a government or local authority push location-based warnings — tsunami, earthquake, flash flood, wildfire, active threat — to every reachable device in an affected region in near real-time. The system fans the same authoritative message out over multiple channels — cell broadcast, mobile push, SMS, and optionally voice call — so that the failure of any single channel does not leave the population un-warned.

This is not a chat app and not a marketing push platform. Two properties dominate every decision. First, the load is burst-shaped and correlated: nothing for weeks, then millions of deliveries inside seconds for one metro region. Second, the disaster itself attacks the infrastructure carrying the alert — towers lose power, backhaul congests, data centers sit in the impact zone. The design must therefore treat delivery as a survivability problem, not a throughput problem.

Why it is distinctive

A marketing system optimizes click-through and tolerates minutes of lag. A disaster system optimizes coverage and tolerates zero false negatives in the warning population. The cost of a missed message is injury or death; the cost of a false alarm is erosion of trust. Both directions matter, which forces two-person authorization, immutable audit, and a fast cancellation path. The 2018 Hawaii false ballistic-missile alert — a wrong dropdown selection that took 38 minutes to correct — is the canonical case that shaped modern admin-console design.

The four architectural planes

  1. Authoring plane: admin console, templates, two-person approval, geo-target selection, cancellation.
  2. Targeting plane: geo-fencing, polygon containment, mapping regions to towers and device cohorts.
  3. Fanout plane: multi-channel dispatch with per-channel adapters, priority queues, deduplication, retries.
  4. Receipt plane: delivery and acknowledgement tracking, coverage metrics, audit evidence.

A strong answer keeps these planes separate so that a slow receipt pipeline never blocks the fanout, and a congested SMS channel never delays the instant cell-broadcast path.

Key Highlights

  • •Load is bursty and geo-correlated: millions of deliveries in seconds, then silence.
  • •The disaster damages the delivery infrastructure, so reliability beats raw throughput.
  • •Two-person authorization and fast cancellation prevent catastrophic false alarms.
  • •Four planes: authoring, targeting, fanout, receipt — each degrades independently.
  • •Cell broadcast is O(number of towers), not O(number of people), which changes the math.
Lead With Survivability, Not Throughput
State in the first two minutes that the disaster damages the delivery path itself. That instantly separates a public-safety design from a marketing-notification clone.
Do Not Treat It Like a Push Service
A design that sends one message per user over one channel misses the defining requirement: redundant multi-channel coverage even when the network is degraded.

Section Rescue Kit

Buzzwords to use:

Cell BroadcastCoverage Versus Latency

Safe statements:

  • "I will separate alert authoring from delivery so a slow channel never delays a faster one."
  • "Before choosing channels, let me define which population segments each one can and cannot reach."
Design a Disaster Alert & Communication System - System Design | WinJob | WinJob