Design a Roadside Assistance Dispatch System

Problem Statement: Roadside Assistance Dispatch

A roadside assistance system connects a stranded driver — dead battery, flat tire, keys locked in, out of fuel, or needing a tow — to the nearest provider who can actually fix that specific problem, quickly and safely. It looks like ride-hailing (send a vehicle to a location), but three differences make it its own problem.

First, the match is by capability, not just proximity. A tow needs a tow truck — and an all-wheel-drive car needs a flatbed, not a hook; a lockout needs lockout tools; a jump-start needs only a service van. Sending the nearest provider who cannot solve the problem is a failed dispatch, so matching filters on what the provider can actually do before it ranks by distance.

Second, the driver usually is not the payer. Coverage comes from a membership (AAA), a manufacturer warranty (new-car roadside), an insurance add-on, or out-of-pocket — and the system must resolve who covers this incident, verify eligibility (is the tow within the covered mileage?), and file the claim. The dispatch and the money are entangled.

Third, safety triage is real. A driver stranded in a live highway lane or on a dark shoulder is in danger; that incident must be prioritized and the driver given safety guidance (stay in the vehicle, hazards on). Demand is also brutally spiky — a cold snap kills thousands of batteries the same morning, a storm strands hundreds at once — so the system must triage by severity when capacity is overwhelmed.

The scale that matters is the provider network and the demand spike, not steady QPS. A national service might handle ~50,000 requests/day (~0.6/s average) across a network of ~30,000 independent providers, but a regional cold snap can spike demand 5–10× in hours. The core is a capability-aware dispatch engine plus a coverage/claims engine over a third-party provider network, with safety triage on top — a logistics-and-eligibility problem wearing a ride-hailing costume.