Design ride hailing: trips, pricing, payments

Once a driver accepts, a ride becomes a trip: a record that changes state about 6 times in half an hour, carries a fare the rider agreed to, and ends with money moving between the rider, the driver and the platform. Across 8 million trips a day that is about 1,390 changes a second in the busiest hour, and none of them may happen twice.

The design rests on three ideas. The trip is a durable state machine: every change is a command with an idempotency key, applied only if it is legal and the trip is still at the version the sender saw. The fare is quoted and locked when the rider confirms, with a surge multiplier smoothed so that it does not flap. And payment is a saga: the money is held at booking, captured when the trip ends and released on cancellation.

About 1,390 trip changes a second, and none may happen twice

Ask these first, and note the answer you assume:

• Where does it start? When a driver accepts an offer, where matching ends.
• How big? 8 million trips a day, each changing state about 6 times; 60 % paid by card, the rest from a wallet, in cash or through a bank app after the ride.
• How are fares set? A quote before booking, from distance, time and a surge multiplier, honoured unless the trip changes materially.
• What goes wrong? Phones retry and drop off the network, riders and drivers cancel, payments fail or report late, and riders dispute fares.
• What must never happen? A rider charged twice, a driver unpaid for a completed trip, or a fare different from the quote without a stated reason.

So every state change must survive a retry or a lost reply without happening twice, a quote must still be honoured minutes later, and a failure of the payment gateway must never stop trips from ending.

The cell size comes from H3’s table of average hexagon areas (H3, cell statistics). None of these numbers is large; what makes the trip side hard is correctness under retries, money that moves in several steps, and prices that change by the minute.

import math

DAY_SECONDS = 86_400


def trip_events_per_second(trips_per_day, events_per_trip, peak_factor):
    """Trip state changes a second in the busiest hour."""
    # Replace this line with your code.
    return 0


def trip_storage_tb_per_year(trips_per_day, bytes_per_trip, copies):
    """TB a year of trip records, in `copies` copies."""
    # Replace this line with your code.
    return 0


def payment_calls_per_second(trips_per_day, card_share, calls_per_card_trip, peak_factor):
    """Payment gateway calls a second in the busiest hour."""
    # Replace this line with your code.
    return 0


def pricing_cells(city_km2, cell_km2):
    """Cells that cover the city, rounded up."""
    # Replace this line with your code.
    return 0

import math

from sizing import payment_calls_per_second, pricing_cells, trip_events_per_second, trip_storage_tb_per_year


def near(actual, expected):
    """Within 10%, as an estimate should be."""
    return math.isclose(actual, expected, rel_tol=0.10)


def test_trip_events():
    """state changes spread over the day, times the peak factor"""
    assert near(trip_events_per_second(8_000_000, 6, 2.5), 1_389)
    assert near(trip_events_per_second(500_000, 8, 3), 139)


def test_trip_storage():
    """a year of records in every copy"""
    assert near(trip_storage_tb_per_year(8_000_000, 5_000, 3), 43.8)
    assert near(trip_storage_tb_per_year(500_000, 4_000, 2), 1.46)


def test_payment_calls():
    """only card trips call the gateway, twice each"""
    assert near(payment_calls_per_second(8_000_000, 0.6, 2, 2.5), 278)
    assert near(payment_calls_per_second(500_000, 0.3, 3, 3), 15.6)


def test_pricing_cells():
    """cells that cover the city"""
    assert near(pricing_cells(600, 0.737), 815)
    assert near(pricing_cells(600, 5.16), 117)

The first design: a trip store, a pricing service and a payment saga

Apps get a quote from the pricing service, which reads supply and demand counts per cell. Commands that change a trip go to the trip service, which writes them to the trip store with conditional writes and an outbox row for each change. The trip event log feeds the payment saga, which talks to the payment gateway and records every movement of money in the ledger, and the services that issue receipts, pay drivers and handle disputes. Follow one trip through it:

The questions this design has to answer:

• Trip states: commands that are retried, reordered or sent by two people at once each apply once or not at all.
• Fares: a quote is locked when the rider confirms and honoured unless the trip changes materially.
• Surge: supply and demand per cell set a multiplier that follows real changes without flapping every minute.
• Payments: a hold at booking, a capture at the end and a release on cancellation form a saga.
• Cash and paying later: a ledger keeps what each driver and rider owes exact.
• After the trip: receipts, payouts and disputes are built from the same events.

An answer is judged on the estimates, the trip’s states, fares and surge, payments by each method, what follows the trip, and failures.

A trip applies each command once, at the version its sender saw Pro: opens with a Pro, Premium or Ultimate pass