Design an On-Demand Tow Truck Dispatch System
You are designing the backend dispatch engine for a nationwide roadside assistance platform. When a motorist requests a tow, the system must find available tow truck drivers in the immediate area, rank them by distance, and offer the job sequentially to the closest driver. Drivers continuously broadcast their GPS location every 10 seconds while on shift.
- Ingest real-time location pings and availability status (Available, Busy, Offline) from 50,000 active drivers every 10 seconds.
- Receive tow dispatch requests from stranded motorists including location coordinates and vehicle type requirements.
- Query nearby available drivers within a configurable search radius (e.g., 15 km) sorted by proximity.
- Manage job offer state machine: offer the job to the nearest driver with a 30-second acceptance timeout, falling back to the next nearest driver upon rejection or timeout.
- Low latency location updates processing (<200 ms ingest to spatial index).
- Strict consistency for job state transitions (exactly-once job assignment).
- High availability for incoming dispatch requests (99.9% uptime).
- Data durability for completed dispatch records and audit logs.
50,000 active drivers sending GPS pings every 10 seconds results in 5,000 writes/second for location updates. Peak demand yields 5,000 tow requests per hour (~1.4 requests/second). Transient location store requires minimal retention (~minutes).
- High-level architecture diagram detailing location ingest pipeline and dispatch engine.
- Data store selection and schema design for transient geospatial index versus persistent dispatch state.
- State transition flow diagram for job assignment, timeout, driver acceptance, and fallback logic.
Candidate selects an appropriate memory-efficient spatial store (e.g., Redis Geospatial, H3, or PostGIS) for driver locations and explains how spatial queries (e.g., GEOSEARCH / radius queries) filter by availability status without locking main database tables.
Candidate designs an efficient ingest flow for 5,000 pings/sec (e.g., lightweight API gateway to an in-memory spatial cache) that decouples location telemetry from persistent storage to avoid database write bottlenecks.
Candidate presents a clear state machine for dispatch (Requested -> Offered -> Accepted/TimedOut/Rejected) using distributed locks or atomic state updates (e.g., CAS operations or Redis script/DB transactions) to guarantee no two drivers accept the same request.
Candidate explains how timer-based offer expirations (e.g., delayed message queues or TTL key-space notifications) trigger re-querying or escalating to the next eligible candidate driver seamlessly.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Follow-up: How would your design handle a scenario where a driver accepts an offer at the exact millisecond their 30-second decision timer expires and the system is transferring the offer to the second-closest driver?
The system must manage 50,000 active drivers reporting location every 10 seconds (5,000 pings/sec). The job assignment process must strictly prevent race conditions where multiple drivers accept the same tow job.
- Views
- 13