Design a superhero incident dispatch system

## System Design: Superhero Dispatch (Uber-like) System Design a system that dispatches superheroes to real-world incidents (e.g., fires, robberies, monster attacks) across a city or globally. ### Scenario - Civilians (or sensors) create **incident requests** with location and details. - The platform finds and assigns an appropriate **superhero** to respond. - Superheroes continuously publish their **live location** while available and en route. ### Functional requirements 1. **Create incident**: Accept a new incident with: - `incident_type` (fire/medical/crime/etc.) - `location` (lat/lon) - `priority` (P0–P3) - optional constraints (needs flying hero, water powers, max response time) 2. **Hero availability**: Heroes can go online/offline and set capability metadata. 3. **Matching/dispatch**: - Find a suitable hero near the incident. - Prefer shortest ETA while satisfying constraints. - Support reassignment if hero rejects/times out. 4. **Trip lifecycle**: Track states such as `CREATED -> MATCHING -> ASSIGNED -> EN_ROUTE -> ARRIVED -> RESOLVED/CANCELED`. 5. **Real-time updates**: - Civilians can see assignment + hero ETA. - Heroes receive incident details and navigation updates. 6. **Reliability**: No double-assigning the same hero to two incidents; handle retries/idempotency. ### Non-functional requirements - Low-latency matching (e.g., p95 < 1–2s for common cases). - High availability; graceful degradation during traffic spikes (e.g., city-wide disaster). - Scalable location ingestion (large number of frequent hero GPS updates). ### What to cover - APIs (high level) - Data model and storage choices - Matching algorithm (including a **geospatial index**) - Architecture/services and communication patterns - Handling failures, race conditions, and hot spots - Scaling plan (partitioning/sharding, caches, queues/streams)