Emergency handling in LLD - System Design Exercise

Design: Emergency Handling System

Includes alert intake, classification, dispatch, status updates, and tracking. Excludes physical responder operations and external communication networks.

Functional Requirements

FR1: Receive emergency alerts from users via multiple channels (phone, app, SMS).

FR2: Automatically detect emergency type (fire, medical, police) and location.

FR3: Dispatch appropriate emergency responders quickly.

FR4: Allow responders to update status and communicate with control center.

FR5: Provide real-time tracking of emergency response progress.

FR6: Store all emergency events and actions for audit and analysis.

Non-Functional Requirements

NFR1: Handle up to 10,000 concurrent emergency alerts.

NFR2: API response time for alert receipt must be under 200ms (p99).

NFR3: System availability must be 99.9% uptime (max 8.77 hours downtime/year).

NFR4: Data consistency for emergency status updates must be strong.

NFR5: Secure sensitive user and location data with encryption.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway for receiving alerts

Alert Classification Service

Dispatch Service

Responder Communication Module

Real-time Tracking Service

Database for storing events and statuses

Authentication and Authorization Service

Notification Service

Design Patterns

Event-driven architecture for alert processing

CQRS for separating read and write workloads

Circuit breaker for external service calls

Retry and fallback mechanisms

Geo-location indexing for quick location queries

Reference Architecture

                +---------------------+
                |  User Devices       |
                | (Phone, App, SMS)   |
                +----------+----------+
                           |
                           v
                +---------------------+
                |    API Gateway      |
                +----------+----------+
                           |
           +---------------+---------------+
           |                               |
           v                               v
+---------------------+         +---------------------+
| Alert Classification |         | Authentication &    |
| Service             |         | Authorization       |
+----------+----------+         +----------+----------+
           |                               |
           v                               v
+---------------------+         +---------------------+
| Dispatch Service     |         | Notification Service|
+----------+----------+         +----------+----------+
           |                               |
           v                               v
+---------------------+         +---------------------+
| Responder Comm.     |         | Real-time Tracking   |
| Module              |         | Service             |
+----------+----------+         +----------+----------+
           |                               |
           +---------------+---------------+
                           |
                           v
                  +---------------------+
                  |    Database          |
                  +---------------------+

Components

API Gateway

RESTful API with HTTPS

Receive emergency alerts from users securely and route to classification.

Alert Classification Service

Microservice with ML-based classifier

Identify emergency type and extract location from alert data.

Dispatch Service

Microservice with rules engine

Assign appropriate responders based on emergency type and location.

Responder Communication Module

WebSocket and push notifications

Enable two-way communication and status updates with responders.

Real-time Tracking Service

Streaming data processor

Track responder locations and emergency progress live.

Database

Relational DB (PostgreSQL) with spatial extensions

Store emergency events, user data, responder status, and audit logs.

Authentication & Authorization Service

OAuth 2.0 / JWT

Secure access for users and responders.

Notification Service

Push notification system (e.g., Firebase, SMS gateway)

Send alerts and updates to users and responders.

Request Flow

1. User sends emergency alert via phone, app, or SMS to API Gateway.

2. API Gateway authenticates request and forwards alert to Alert Classification Service.

3. Classification Service determines emergency type and extracts location.

4. Dispatch Service receives classified alert and assigns responders based on rules.

5. Responder Communication Module notifies responders and enables status updates.

6. Responders update status and location, sent to Real-time Tracking Service.

7. Tracking Service updates emergency progress visible to control center.

8. All events and updates are stored in the Database for audit and analysis.

Database Schema

Entities: - User (user_id PK, name, contact_info, encrypted_data) - EmergencyAlert (alert_id PK, user_id FK, type, location, timestamp, status) - Responder (responder_id PK, name, role, contact_info, status) - DispatchRecord (dispatch_id PK, alert_id FK, responder_id FK, assigned_time, status) - StatusUpdate (update_id PK, dispatch_id FK, timestamp, location, status_detail) Relationships: - User 1:N EmergencyAlert - EmergencyAlert 1:N DispatchRecord - DispatchRecord 1:N StatusUpdate - Responder 1:N DispatchRecord

Scaling Discussion

Bottlenecks

API Gateway overload with high concurrent alert volume.

Classification Service latency under heavy load.

Database write contention for status updates.

Real-time tracking data processing bottleneck.

Notification Service delays during peak times.

Solutions

Use load balancers and auto-scaling groups for API Gateway.

Implement asynchronous processing and batch classification with message queues.

Use database sharding and optimized indexing for writes.

Adopt stream processing platforms (e.g., Apache Kafka, Flink) for tracking data.

Use multiple notification providers and rate limiting to handle spikes.

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Clarify emergency types and user channels early.

Explain choice of event-driven architecture for responsiveness.

Discuss data consistency needs for status updates.

Highlight security and privacy considerations.

Address scaling challenges with concrete solutions.

Show understanding of real-time communication and tracking.

Practice

1. What is the primary goal of an emergency handling system in system design?

easy

A. To detect problems quickly and protect people and property

B. To increase system performance under normal conditions

C. To reduce the cost of hardware components

D. To provide detailed analytics for marketing purposes

Solution

1. Step 1: Understand the purpose of emergency handling

   Emergency handling systems are designed to detect issues fast and act to prevent harm.

2. Step 2: Identify the main goal

   The main goal is to protect people and property by quick detection and response.

3. Final Answer:

   To detect problems quickly and protect people and property -> Option A

4. Quick Check:

   Emergency handling = fast detection and protection [OK]

Hint: Focus on safety and speed in emergencies [OK]

Common Mistakes:

• Confusing emergency handling with performance optimization
• Thinking it is about cost reduction
• Assuming it is for marketing analytics

2. Which component is NOT typically part of an emergency handling system?

easy

A. Safety action controller

B. Alerting system

C. Detection module

D. User interface for marketing

Solution

1. Step 1: List typical components

   Emergency handling systems usually have detection, alerting, safety actions, and logging.

2. Step 2: Identify the unrelated component

   User interface for marketing is unrelated to emergency handling functions.

3. Final Answer:

   User interface for marketing -> Option D

4. Quick Check:

   Marketing UI ≠ emergency handling component [OK]

Hint: Exclude marketing from emergency system parts [OK]

Common Mistakes:

• Including unrelated business components
• Confusing alerting with marketing notifications
• Ignoring safety action controllers

3. Consider this simplified emergency system flow:
if sensor.detect(): alert.send(); safety.activate(); log.record()
What happens if sensor.detect() returns false?

medium

A. Alert, safety, and log actions all execute

B. Only alert and safety actions execute

C. No actions execute

D. Only log action executes

Solution

1. Step 1: Analyze the if condition

   The actions alert.send(), safety.activate(), and log.record() run only if sensor.detect() is true.

2. Step 2: Determine behavior when sensor.detect() is false

   If sensor.detect() returns false, the code block inside if does not run, so no actions execute.

3. Final Answer:

   No actions execute -> Option C

4. Quick Check:

   False detection = no emergency actions [OK]

Hint: If condition false means skip all inside actions [OK]

Common Mistakes:

• Assuming log always runs regardless of detection
• Thinking alert or safety run without detection
• Confusing else behavior when none is given

4. In an emergency system, this code snippet causes a problem:
if sensor.detect():
alert.send()
safety.activate()
log.record()
What is the main issue?

medium

A. Missing indentation causes log.record() to run always

B. safety.activate() is outside the if block

C. alert.send() is not called properly

D. log.record() runs even if no detection

Solution

1. Step 1: Check code indentation

   log.record() is not indented under the if, so it runs always.

2. Step 2: Understand impact

   log.record() runs even when sensor.detect() is false, which is incorrect behavior.

3. Final Answer:

   Missing indentation causes log.record() to run always -> Option A

4. Quick Check:

   Indentation controls conditional execution [OK]

Hint: Indent all emergency actions inside detection check [OK]

Common Mistakes:

• Ignoring indentation importance
• Assuming all lines are inside if by default
• Confusing which lines run conditionally

5. You design an emergency system that must alert multiple teams and log events reliably. Which design approach best ensures alerts are sent even if one alert service fails?

hard

A. Send alerts sequentially and stop on first failure

B. Send alerts in parallel with retries and fallback logging

C. Send alerts only to the primary team to reduce complexity

D. Log events only after all alerts succeed

Solution

1. Step 1: Understand reliability needs

   To ensure alerts reach multiple teams, sending in parallel avoids blocking on one failure.

2. Step 2: Use retries and fallback logging

   Retries help recover from temporary failures; fallback logging records failures for later review.

3. Final Answer:

   Send alerts in parallel with retries and fallback logging -> Option B

4. Quick Check:

   Parallel + retries = reliable alerting [OK]

Hint: Use parallel alerts with retries for reliability [OK]

Common Mistakes:

• Stopping alerts on first failure
• Ignoring retries and fallback mechanisms
• Reducing alert recipients to simplify