Stripe·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

Stripe system design round, one big question about building a superhero dispatch platform. Think Uber but for saving the world. The scope was wide enough that I kept second-guessing which parts to go deep on.

Questions Asked (1)

Design a superhero dispatch system that matches available superheroes to incoming world events in real time, similar to how a ride-sharing platform assigns drivers to riders. Walk through event ingestion, hero availability tracking, geospatial indexing to find the nearest hero, the matching service, real-time updates, and how you'd scale the whole thing.

System DesignTechnical Trade-offsAlgorithms & Data Structures

Author's notes

I spent way too long on event ingestion and didn't get to geospatial indexing until they nudged me.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a high-level architecture that separates event ingestion, hero availability tracking, geospatial indexing, and matching. Walk through each component, explaining data models, algorithms, and trade-offs, and finish with scaling strategies like sharding, caching, and asynchronous processing.

Pro tip: Emphasize idempotency and exactly-once processing for event ingestion and matching, as duplicate assignments or missed events are critical failures in real-time dispatch systems. Also, discuss how you'd handle hero unavailability mid-assignment to avoid race conditions.

1. Clarify Requirements and Scale

Ask about expected event volume, number of heroes, geographic distribution, latency requirements, and consistency needs. Define functional and non-functional requirements to guide design decisions.

2. High-Level Architecture

Outline the main components: event ingestion (API gateway, message queue), hero availability service, geospatial index, matching engine, and notification system. Sketch data flow from event creation to hero assignment.

3. Deep Dive into Key Components

Detail event ingestion (e.g., Kafka for durability), hero tracking (heartbeats, location updates), geospatial indexing (e.g., geohash, quadtree, or PostGIS), and matching algorithm (nearest available hero with constraints). Discuss real-time updates via WebSockets or push notifications.

4. Address Trade-offs and Edge Cases

Discuss consistency vs. availability (CAP), latency vs. accuracy in geospatial queries, and handling failures (hero disconnects, event cancellations). Explain how to prevent duplicate assignments and ensure idempotency.

5. Scaling Strategy

Describe horizontal scaling of services, sharding by geography, caching hot data, using CDNs for static assets, and employing load balancers. Mention monitoring, auto-scaling, and capacity planning.

Key Points to Mention

Geospatial indexing techniques (geohash, quadtree, R-tree) and their trade-offs for nearest-neighbor search.
Event ingestion pipeline with message queues (Kafka, RabbitMQ) for durability and backpressure handling.
Hero availability tracking using heartbeats and consistent hashing for sharding hero state.
Matching algorithm considering distance, hero capabilities, and current load, with idempotent assignment.
Real-time communication via WebSockets or server-sent events for pushing assignments to heroes.
Scaling via geographic sharding, read replicas, caching, and asynchronous processing to handle high throughput.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.