Design Lyft

Problem statement

Design Lyft: a ride-hailing marketplace where riders request trips, the platform matches them to nearby drivers within seconds, both parties track each other in real time, the fare is computed with a transparent demand-based pricing model, and the rider can tip the driver in-app after the trip. The system must handle rider sign-up and ride requests, driver sign-up and offer acceptance, basic real-time location and ETA, and an in-app tipping flow that moves money correctly.

The defining property of this system is that it is a two-sided marketplace with perishable inventory: an idle driver-minute and an unserved rider-minute both expire. Matching is therefore not a lookup, it is an optimization over a constantly moving supply and demand set, executed in short batches so that one rider's match does not steal a better driver from another rider who requested 200 ms earlier.

Why Lyft is not 'Uber but smaller'

A strong answer names the product differences that change the architecture. First, Lyft pioneered in-app tipping in 2017, before Uber shipped it; tips are a first-class money movement with its own ledger, amendment window, and payout path, not a field on the fare. Second, Lyft's demand pricing has historically been presented as a transparent percentage add-on (Prime Time) rather than an opaque multiplier, which changes quote immutability and rider-trust requirements. Third, Lyft leans on cost-sharing products such as pooled rides (Lyft Line) and Wait & Save style delayed-ride discounts, so the matcher must reason about seat capacity and detour budgets, not just one rider per car. Fourth, Lyft operates at roughly one fifth to one quarter of Uber's trip volume in the US, so the design must scale gracefully from a regional marketplace to national peaks without assuming infinite engineering headcount.

Public baseline versus design assumptions

Lyft's public filings and shareholder letters describe on the order of twenty million active riders and several hundred million rides per year, with quarterly ridership in the low tens of millions; those are company-reported figures used only for context. For capacity planning this answer explicitly assumes: 25 million active riders, 2.1 million rides per day, a 4x peak multiplier on request arrivals, 400 thousand concurrently active drivers at peak, a 4-second driver location cadence, and 300 thousand concurrent in-ride tracking sessions. Every uncited number in this answer is a stated assumption, budget, or target.

The five planes of the design

1. Experience plane: rider app, driver app, web, support console.
2. Marketplace plane: quoting, batched dispatch, offer leases, pooling groups, airport virtual queues.
3. Real-time plane: location ingestion, geospatial indexes, ETA service, WebSocket fan-out.
4. Money plane: fare settlement, Prime Time pricing, tip ledger, driver payouts, refunds.
5. Trust plane: identity, background checks, safety toolkit, fraud, privacy, city reporting.

Keeping these planes separate is what lets the pricing engine degrade to cached percentages while dispatch keeps matching, and lets the tip ledger stay correct while the tracking feed is stale.