How Uber matches drivers in real time

In February 2022, Uber described how it improved arrival-time predictions used in rider matching (DeepETA).

Uber completes more than 40 million trips daily, and ETA is a core part of their system.

Uber initially matched each rider with the closest available driver. That could leave other riders waiting much longer (Uber Marketplace).

In this blog, we will see how Uber's engineers solved the following problems.

1. The nearest driver on a map might take longer to reach the pickup.
2. Choosing the best driver for one rider could make the next rider's match worse.

1. Matching riders together

When you book a cab, the driver has to reach your pickup location before your trip starts. That journey determines your pickup wait.

A driver across a river might look close on the map. Reaching the bridge and driving back can make the pickup slow.

The main idea behind driver matching is to reduce overall wait times. If two riders have to be matched with two drivers, we connect them in a way that minimizes average wait time.

The two riders are A and B; the drivers are X and Y. These illustrative pickup estimates make the tradeoff visible:

If A requests first, choosing X gives A a two-minute pickup. B gets Y and waits twelve minutes.

The total is fourteen minutes. Each rider waits seven minutes on average.

But assign Y to A and X to B instead. Both wait three minutes, giving six minutes in total.

A waits one minute longer. B saves nine minutes. Looking at both requests changes the decision.

2. Waiting to make a better match

How can the matcher see both riders before committing a driver? It needs a short interval in which requests accumulate.

For efficiency, this is done in batch, where multiple riders are connected with multiple drivers.

Uber describes evaluating nearby riders and drivers together in the seconds after a request. Its goal is a lower collective wait (Uber Marketplace).

The batch also makes riders wait before assignment. Our example should charge that delay to the proposed improvement.

Suppose each rider spends four seconds waiting for this batch. That delay is an illustrative assumption. Uber's page does not specify this batch duration.

immediate = 2 * 60 + 12 * 60
batched_pickup = 3 * 60 + 3 * 60
batch_wait_per_rider = 4
batched_total = batched_pickup + 2 * batch_wait_per_rider
print("Immediate total:", immediate, "seconds")
print("Batched total:", batched_total, "seconds")
print("Time saved:", immediate - batched_total, "seconds")

Immediate total: 840 seconds
Batched total: 368 seconds
Time saved: 472 seconds

The saving survives this small delay. It would disappear if each rider waited four additional minutes before the same three-minute pickup.

That comparison measures request-to-pickup time. Optimizing only the driving portion could hide a slow assignment process.

3. Finding nearby candidates

You can't compare every rider with every driver in every city. A geographic index helps narrow the candidate search.

Uber described its H3 geographic index in June 2018. It groups locations into a hierarchy of cells for marketplace analysis and optimization (Uber H3).

In our example, the candidate search must find X and Y near A and B. Comparing those candidates is cheaper than scanning the entire fleet.

But a cell boundary isn't a wall. A nearby driver can stand just across it.

A search limited to the rider's own cell could miss that driver. Checking surrounding cells and applying a distance filter is a design option for avoiding that mistake.

That candidate-search example is a design explanation. Uber's posts do not establish that every matching batch is restricted to one H3 cell.

H3 supports exact logical parent-child relationships, but geographic containment is approximate (H3 hierarchy documentation). Its parent lookup functions encode that hierarchy correctly.

4. Predicting pickup time

Finding X and Y does not tell us which driver reaches A sooner. We still need the pickup estimates in the table.

For pickup estimates, Uber's February 2022 DeepETA post describes a routing engine followed by an ML correction. The model predicts the error in the routing estimate (DeepETA).

Its inputs include origin, destination and request time. Uber selected an architecture with self-attention and optimized it for low latency.

For A and B, the matcher needs estimates for each feasible pairing. A wrong estimate can reverse the decision even when the matching logic is correct.

Suppose Y's pickup for A takes fifteen minutes instead of the predicted three. The chosen pairing now costs eighteen minutes before assignment delays.

Compared with that pairing, our earlier fourteen-minute option would have been better. This is why an efficient matcher still depends on prediction quality.

The transformer drawing illustrates the model conceptually, as it does in the reel. The linked DeepETA post documents the production model's specific architecture.

5. Keeping a driver available for the next rider

What if both matches look good now, but leave no drivers where the next requests are likely? The matcher also changes the city's future supply.

In July 2025, Uber described using a learned value function to influence online matching. It scores future driver states instead of directly learning the matching policy (Uber engineering).

For our two drivers, that adds another consideration: where X and Y will finish their trips. A slightly different pairing may leave supply in more useful locations.

Uber reported 2.2% fewer rider cancellations and a 0.52% increase in driver earnings in its experiments. Those results describe that deployment. They do not predict the outcome of our example.

The post also describes reducing the model signal's influence when monitored performance degrades. A learned signal does not get unlimited authority over matching.

6. Final request flow

What happens to the two requests once the matcher has all these inputs? This is the teaching flow from the reel, rather than an internal API specification.

1. Gather nearby rider and driver candidates into a short matching batch.
2. Estimate pickup times for feasible pairs, then evaluate the assignments together.
3. Include future marketplace value when choosing matches and track the resulting wait times.

For A and B, the best result came from considering both requests. Waiting briefly gave the matcher a choice that the immediate assignment had already removed.

For the services behind this matching decision, continue with Uber Ride Matching.

Summary

• Matching riders in a batch can reduce their combined pickup wait. The time spent waiting for assignment must count too.
• H3 narrows geographic searches. Routing and ETA predictions help compare the drivers who can reach each pickup.
• A match changes future driver availability. Uber uses a learned value signal to account for that effect alongside immediate pickup times.