The product: a ride exchange

The product: a ride exchange

The obvious design is to treat ride hailing as ordinary request/response CRUD: a rider asks for a row, a driver updates a row, and a backend coordinates the rest. It makes the happy path simple, but it protects the wrong property. The exchange core must clear time-sensitive rider demand against changing driver supply, while slower settlement and reporting work remains outside that latency boundary.

Uber is an exchange: riders submit bids for transportation (demand orders), drivers stream availability (supply orders), and a matching engine continuously clears the market under latency constraints, with price (surge) as the balancing mechanism. Framing it as an exchange is more than a metaphor — it dictates the architecture. Like a financial exchange, the core loop (order in → match → execution) must be extremely fast and extremely available, while everything around it (settlement, reporting, analytics) can be slower and more forgiving. That asymmetry is the seed of Parts 2 and 3.

The system in context

flowchart LR
  R["📱 Rider app"] --> X
  D["🚗 Driver app"] --> X
  OPS["🖥️ City ops and support staff"] --> X
  subgraph X ["RideX — the ride exchange"]
    CORE["Exchange core: presence, matching, trips, pricing"]
    SUPPORTING["Supporting: identity, payments, comms, ratings"]
    PLATFORM["Platform: infra, observability, data and BI"]
  end
  X --> MAPS["🗺️ Map and routing provider"]
  X --> PSP["💳 Payment service provider"]
  X --> KYCV["🪪 Identity and background-check vendor"]
  X --> TEL["📞 Telephony, SMS and push vendors"]
  X --> REG["🏛️ Regulators and tax authorities"]

Functional requirements

We will cover a deliberately broad slice of the real product. Grouped by who they serve:

Now consider what happens when a maps or payment vendor is unavailable while riders and drivers are still trying to form trips. If the central guarantee disappears here, the design has confused an optimization with a correctness boundary.