Katkat
Back

Design a Superhero Dispatch System

StripeSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question evaluates a candidate's ability to design reliable, distributed backend systems with emphasis on transactional correctness, concurrency control for single-winner acceptance races, geo-spatial querying for proximity matching, eventing/notification pipelines, and operational observability for mission-critical dispatch.

Design the backend for a superhero rescue marketplace — a dispatch platform that connects civilians in distress with nearby superheroes.

Civilians report emergencies (accidents, fires, crimes). For each report the platform must create a rescue request, identify appropriate nearby superheroes, notify them, let exactly one hero accept the request and travel to the incident, and let dispatchers monitor request status end to end. The problem is structurally similar to ride-hailing dispatch (Uber/Lyft), but with two important differences: request volume is far lower than a major ride-sharing platform, and reliability matters more than maximizing throughput — a dropped or double-assigned emergency is a much worse failure than a dropped ride request.

Focus on system architecture and technical tradeoffs, not on REST/RPC endpoint design. The interviewer's primary signal is the strength of your justification for each technology and consistency choice. Your design should address: functional and non-functional requirements; the main services and the storage chosen for each; the data model for civilians, heroes, incidents, offers, and assignments; how hero location and availability are tracked and queried by radius; matching and dispatch logic; the incident state machine from creation to completion; concurrency control for the core acceptance race; notifications, offer timeouts, retries, and failure handling; and observability and operational concerns.

Constraints & Assumptions

State your own numbers, but a reasonable working set is:

  • ~1,000,000 registered civilians; ~10,000 heroes active in a large metro area.
  • Peak load ~500 new incidents per minute metro-wide (far below ride-hailing's millions/hour) — the system is write-light but correctness-critical; do not over-engineer for millions of QPS.
  • Hero location pings every 5–15 seconds while on duty.
  • Target time-to-first-offer: low single-digit seconds; offer-acceptance window ~10–20 seconds.
  • A single-hero assignment is the default; multi-hero incidents are an extension, not the base case.
  • Hard correctness invariant: a single-hero incident must end up assigned to at most one hero, even under concurrent acceptances and partial failures.
  • Eventual consistency is acceptable for live-location display, dashboards, and analytics; strong consistency is required for the final assignment.

Clarifying Questions to Ask

  • Can a single incident require multiple heroes (e.g. a large fire needing a medic plus a fire-rescue hero), or is it always one hero per incident in scope?
  • What does "nearby" mean — straight-line radius, or estimated travel time accounting for the hero's mode (ground vs. flight)?
  • How aggressively may we contact a hero — push-only, or escalate to SMS / voice for severe incidents — and is there an SLA for reaching one?
  • Is there a human dispatcher in the loop as a fallback, and can they manually override, cancel, or reassign?
  • What are the relative consequences of a false dispatch (sending a hero who isn't really needed) versus a missed dispatch?
  • What is the data-retention / auditability requirement for incidents (regulatory or post-incident review)?

Hints

Hint 1

Where to start: Different parts of this system have very different correctness needs. Before picking any storage engine, sort your data into two buckets: the one piece you absolutely cannot get wrong (the final assignment) versus the pieces you can afford to have slightly stale (live location, dashboards, analytics). Most later choices fall out of that split.

Hint 2

The core race: Two heroes tapping "accept" at the same instant is the crux. A two-step "check if still open, then write" has a window between the check and the write where both can pass. Think about whether acceptance can instead be expressed as a *single* operation that can only succeed for one hero — and how a hero would learn whether they won or lost. Then be ready to argue *which component* should be the authority that enforces this (an app-level lock? the datastore itself?) and why.

Hint 3

Location vs. truth: Hero GPS is high-churn and only the freshest value matters. Consider whether the structure that efficiently answers "who is near this incident *right now*?" has to be the same store you trust at commit time, or whether you can separate the read path used for *matching* from the transactional store used for *assignment* — and what each kind of store is good at.

Hint 4

Don't lose the request: For an emergency platform the nastiest failure is the quiet one: the request persists but the downstream dispatch work never kicks off. Notice that "write the incident to the DB" and "tell the rest of the system to start dispatching" are *two separate side effects* — if they aren't tied together, one can succeed while the other silently fails. Think about how to make those two outcomes share a single fate rather than relying on a best-effort write-then-publish.

Follow-up questions

  • A city-wide disaster causes a 50× burst of incidents in one neighborhood while the rest of the metro is quiet. What degrades first, and how do you keep the system from melting down?
  • Extend the design to **multi-hero incidents** that need several heroes with complementary skills arriving together — how do matching, offers, and the state machine change, while still guaranteeing no hero is double-booked?
  • An assigned hero goes **unreachable mid-rescue** (missed heartbeats) and never marks the incident resolved. How do you detect this and safely reassign without double-dispatching or stranding the civilian?
  • You must add a machine-learned model that predicts each hero's acceptance probability and ETA to improve ranking. Where does it sit in the architecture, and how do you keep matching latency in seconds?