Cab booking

The problem

Riders request a trip from A to B. The system finds a nearby available driver, the driver accepts, the trip happens, and the rider pays. Drivers go online and offline and move continuously.

Entities

100%

Figure SDA-LLD-08-1 · Cab booking classes · © forcsguy.com

The trip lifecycle

100%

Figure SDA-LLD-08-2 · Trip states · © forcsguy.com

Matching

100%

Figure SDA-LLD-08-3 · Matching a request · © forcsguy.com

interface MatchingStrategy { choose(req: Request, candidates: Driver[]): Driver | null }
const nearest: MatchingStrategy = {
  choose: (req, ds) => ds.sort((a, b) => dist(a.loc, req.pickup) - dist(b.loc, req.pickup))[0] ?? null,
};

class TripService {
  request(rider: Rider, pickup: Point, dropoff: Point): Trip {
    const trip = new Trip(rider, pickup, dropoff);          // REQUESTED
    for (const d of this.locations.nearby(pickup, 3_000)) { // candidates
      if (d.tryClaim(trip.id)) return trip.offerTo(d);      // atomic: one trip per driver
    }
    return trip.cancel("no drivers");
  }
}

tryClaim is atomic so a driver cannot be offered two trips at once. The location lookup is a spatial index (geohash or quadtree; see the nearby-places lesson).

Design notes

• Pricing is a strategy (base, per km, per minute, surge) and the fare is stored on the trip when booked.
• Live location updates are frequent and approximate; keep them in a fast store and do not write every point to the main database.
• Notifications to rider and driver on each state change use the Observer pattern.
• Edge cases: driver goes offline mid-offer, rider cancels after pickup, payment fails (retry, then flag the account).
• Extensions: shared rides, scheduled rides, ratings, and driver incentives.

Real-world reading