Building for the trip that goes wrong

It is easy to build the trip that works. Rider books, driver accepts, everyone arrives. That path is short and pleasant and represents the great majority of trips.

It also generates almost none of the operational cost. The cost is in the small minority where something did not go to plan, and a platform is really judged on those.

No driver found

A scheduled trip whose search finds nobody cannot simply fail silently. The job retries rather than giving up on the first attempt, because supply at 06:50 is not supply at 06:58.

What it must never do is retry forever while the rider assumes a car is coming. Bounded retries with a clear outcome are the requirement.

Payment succeeded, trip did not

The dangerous ordering. If money moves and then trip creation fails, you have taken payment for nothing. This is why card payments create the trip once the payment clears rather than optimistically before, and why financial writes carry idempotency keys.

The rider is not there

Waiting time is recorded, with a grace period, because a driver waiting is working. Beyond that there has to be a defined end state rather than an indefinite wait, and it has to be one the driver can trigger.

Something went wrong mid-trip

Safety reports and SOS attach to the trip and reach a desk that can see it. The design requirement is that the person responding starts with the full record rather than a phone call and a blank page.

A generator that runs twice

Anything scheduled will eventually run twice, or run after a partial failure. Recurring ward trips carry a key per arrangement, date and leg, so a second run books nothing new. Designing for the re-run is cheaper than detecting the duplicate afterwards.

The general principle

Ask what happens when each step fails, and make sure the answer is a state somebody can act on. Software that only describes success leaves its failures to be handled by a support agent at nine on a Friday evening.