Requirements

In one line: two entries in the non-functional list — strong consistency and fraud detection — have not appeared in any problem chapter so far. Both change the architecture.

Functional requirements

Seven of the nine are transitions in one state machine

Laid out in order, the list is not nine features — it is a lifecycle:

find nearby drivers -> request a ride -> show ETA -> confirm pickup
                    -> show trip updates -> end the trip -> manage payments

Only update driver location and notifications sit outside it, and both are infrastructure that the lifecycle depends on rather than steps within it.

Reading the list this way changes how you present the design. A candidate who enumerates nine features sounds like they are reciting; one who says "these are the transitions of a trip, plus a location stream and a delivery mechanism" has understood the system.

It also predicts the components. Lesson 8's trip manager exists precisely because a long-lived state machine needs an owner — something that knows a trip is in ACCEPTED rather than IN_PROGRESS and refuses invalid transitions.

Ranking is mentioned once and then dropped

Note: Drivers can be ranked not only by proximity but also by ratings, popularity, or other relevance metrics to optimize matching.

This note is doing more work than its placement suggests, and the design never returns to it.

"Find the nearest driver" is a proximity query — Yelp's problem with moving points. But "find the best driver" is an optimization problem, and the two have different answers:

• The nearest driver may be pointed the wrong way down a one-way street, so a driver 500 metres further away arrives sooner. Nearest by distance is not nearest by time.
• A driver about to finish a nearby trip may be a better match than an idle one further out.
• Matching one rider greedily to the closest driver can leave a worse global assignment. Real systems solve batched bipartite matching over a short window rather than matching each request on arrival.

The design poses a related question and leaves it open: "What if two drivers are at the same distance from the rider? How will we select the driver?"

The honest answer is that distance was never the right criterion — you break the tie on ETA, which the design already computes, and then on driver rating, acceptance rate, and how long each has been idle. Fairness to drivers is a real consideration here, not a nicety: a matching system that always prefers the same drivers starves the rest.

Worth raising unprompted. Matching is where ride-hailing companies actually compete, and a design that treats it as "find the nearest" has skipped the interesting part.

Non-functional requirements

Strong consistency — the first problem chapter to demand it, and it is correct

Every problem chapter so far has settled for eventual consistency, and rightly. YouTube view counts, Quora answer ordering, Yelp ratings — staleness in all of them is invisible.

Here it is not, and the design's justification is exactly right: "drivers and riders share a unified view of the trip state."

Consider what divergence means physically. The rider's phone says the driver is arriving; the driver's says the trip was cancelled. Someone is standing on a street corner. No amount of eventual convergence undoes that.

But be precise about what needs strong consistency, because applying it everywhere would be ruinous:

That table is the whole polyglot storage argument in Lesson 10 — MySQL for in-progress trips, Cassandra for locations and completed trips. The requirement does not say "the system is strongly consistent"; it says the trip state is. Those are very different systems.

Scope the consistency requirement to the data that needs it. A candidate who says "strong consistency" without saying for what has committed to paying for it on 750,000 writes per second.

Fraud detection as a non-functional requirement is unusual and welcome

The Yelp chapter's largest gap was that nothing defended against review fraud. Here, fraud is named in the requirements and given a dedicated system.

That elevation matters, because adversarial requirements behave differently from every other kind:

They do not converge. Availability, once engineered, stays engineered. Fraud defences degrade continuously because an adversary is adapting to them — the design draws the analogy to zero-day exploits.

They are asymmetric. As the design notes, "although fraud represents a small fraction of gross bookings, it can result in disproportionate revenue loss" — and it compounds, because a working exploit gets shared and scaled.

They cannot be fully automated. Lesson 13's RADAR keeps a human analyst in the loop deliberately, which limits scale and improves decision quality.

There is a structural reason fraud is worse here than at Yelp: the fraud is against money, and the system controls the money. A fake review distorts a ranking. A manipulated GPS trace produces a payout. When the thing being gamed is the thing being paid out, the incentive is direct and immediate.

Reliability and availability are stated separately, and here the distinction is real

Most chapters treat these as near-synonyms. The design separates them, and its wording justifies the split:

Availability — "downtime disrupts active trips and prevents users from contacting each other." The system is reachable.

Reliability — "services must be error-free." The system does the right thing when reached.

The gap between them is where this design gets interesting. A partially-available system that mismatches a driver or double-charges a rider is reachable and wrong. Lesson 11's offline handling — the driver's phone persisting trip state locally and replaying pending requests — is a reliability mechanism, not an availability one. It does not keep the server up; it keeps the trip correct across a network gap.

Availability is about the system being there. Reliability is about the outcome being right. In a system that commits people to physical actions, the second matters more.

Worth separating out: most requirements here are about speed, but exclusivity in matching is about correctness. Two riders being offered the same driver at the same instant is not slow, it is wrong — and that distinction determines the mechanism.

Next: the estimation, and the number it never computes.