Sign in to track progress, unlock prep layers, and browse your pipeline.Sign in
Design a Superhero Incident Dispatch System
Design a system capable of dispatching superheroes to real-world incidents (e.g., fires, robberies, monster attacks) across a city or globally, similar to a ride-sharing platform.
Scenario
- Civilians or automated sensors create incident requests, providing location and detailed information.
- The platform's core function is to identify and assign the most appropriate superhero to respond to each incident.
- Superheroes, while available and en route, continuously publish their live location to the system.
Functional Requirements
- Create Incident: The system must accept new incident requests, including:
incident_type(e.g., fire, medical, crime)location(latitude/longitude coordinates)priority(P0–P3, where P0 is highest)- Optional constraints (e.g., requires a flying hero, water powers, maximum response time).
- Hero Availability: Superheroes can toggle their online/offline status and configure their capabilities/metadata (e.g., powers, equipment).
- Matching and Dispatch: The system must:
- Find a suitable hero geographically near the incident.
- Prioritize heroes based on the shortest estimated time of arrival (ETA) while satisfying all incident constraints.
- Support reassignment if an initially assigned hero rejects the incident or times out.
- Trip Lifecycle: Track the state of an incident through its lifecycle:
CREATED -> MATCHING -> ASSIGNED -> EN_ROUTE -> ARRIVED -> RESOLVED/CANCELED. - Real-time Updates: Provide real-time information:
- Civilians should be able to view the assigned hero's details and ETA.
- Heroes should receive incident details and navigation updates.
- Reliability: Ensure robust operation, specifically:
- Prevent double-assigning the same hero to multiple incidents simultaneously.
- Handle retries and ensure idempotency for critical operations.
Non-Functional Requirements
- Low-latency Matching: P95 matching time should be less than 1–2 seconds for common cases.
- High Availability: The system must remain highly available, with graceful degradation during extreme traffic spikes (e.g., a city-wide disaster).
- Scalable Location Ingestion: Capable of ingesting a large volume of frequent GPS updates from numerous heroes.
What to Cover in Your Design
- High-level APIs for key interactions.
- Data model and appropriate storage choices.
- The matching algorithm, specifically incorporating a geospatial index.
- Overall architecture, including services and their communication patterns.
- Strategies for handling failures, race conditions, and hot spots.
- A comprehensive scaling plan, covering partitioning/sharding, caching, and the use of queues/streams.
AI interview prep
Core dilemma
Balancing extreme real-time data ingestion (hero locations) and low-latency, geographically-aware matching with strong consistency guarantees for assignments, all under high availability and potential disaster-level load.
Mid-level signals3
Senior signals4
Red flags4
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design a Superhero Incident Dispatch System
Design a system capable of dispatching superheroes to real-world incidents (e.g., fires, robberies, monster attacks) across a city or globally, similar to a ride-sharing platform.
Scenario
- Civilians or automated sensors create incident requests, providing location and detailed information.
- The platform's core function is to identify and assign the most appropriate superhero to respond to each incident.
- Superheroes, while available and en route, continuously publish their live location to the system.
Functional Requirements
- Create Incident: The system must accept new incident requests, including:
incident_type(e.g., fire, medical, crime)location(latitude/longitude coordinates)priority(P0–P3, where P0 is highest)- Optional constraints (e.g., requires a flying hero, water powers, maximum response time).
- Hero Availability: Superheroes can toggle their online/offline status and configure their capabilities/metadata (e.g., powers, equipment).
- Matching and Dispatch: The system must:
- Find a suitable hero geographically near the incident.
- Prioritize heroes based on the shortest estimated time of arrival (ETA) while satisfying all incident constraints.
- Support reassignment if an initially assigned hero rejects the incident or times out.
- Trip Lifecycle: Track the state of an incident through its lifecycle:
CREATED -> MATCHING -> ASSIGNED -> EN_ROUTE -> ARRIVED -> RESOLVED/CANCELED. - Real-time Updates: Provide real-time information:
- Civilians should be able to view the assigned hero's details and ETA.
- Heroes should receive incident details and navigation updates.
- Reliability: Ensure robust operation, specifically:
- Prevent double-assigning the same hero to multiple incidents simultaneously.
- Handle retries and ensure idempotency for critical operations.
Non-Functional Requirements
- Low-latency Matching: P95 matching time should be less than 1–2 seconds for common cases.
- High Availability: The system must remain highly available, with graceful degradation during extreme traffic spikes (e.g., a city-wide disaster).
- Scalable Location Ingestion: Capable of ingesting a large volume of frequent GPS updates from numerous heroes.
What to Cover in Your Design
- High-level APIs for key interactions.
- Data model and appropriate storage choices.
- The matching algorithm, specifically incorporating a geospatial index.
- Overall architecture, including services and their communication patterns.
- Strategies for handling failures, race conditions, and hot spots.
- A comprehensive scaling plan, covering partitioning/sharding, caching, and the use of queues/streams.