Uber Eats halved search time through many fixes, the largest around 200 ms
Uber Eats halved its search wait with no single change worth more than about 200 ms, a DEV Community summary of Uber Engineering's post says. The biggest saving came after Uber started timing the first fully drawn screen on the phone.
The Engineer · Build desk
Time saved by separate changes to Uber Eats search: removing slow word-matching retrieval strategies, about 120 ms; splitting hydration, more than 100 ms; request hedging, 40 ms; removing false dependencies, about 35 ms.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Slow word-matching retrieval strategies removed | 120 ms, about | 8 | |
| Split hydration | 100 ms, more than | 10 | |
| Request hedging | 40 ms | 12 | |
| False dependencies removed | 35 ms, about | 11 |
What happened
- Under the new clock the first problem was plain: the server built every result, one card at a time, before it sent any of them.
- Uber now sends a small first page, caches the rest for scrolling and renders cards concurrently; together the two changes brought the first screen more than 200 ms sooner.
- Dropping several slow, broad word-matching retrieval strategies that added little saved about 120 ms, by deleting code.
- Splitting hydration into ranking and presentation fetches that run in parallel was worth more than 100 ms.
- Request hedging, which resends a stalled shard's request to another copy and keeps the first answer, saved 40 ms.
Why it matters
- What it limits constraint Backend response time stops before the network trip, card building and photo loading, so a dashboard built on it cannot show where this kind of saving comes from.
- What it costs cost Reaching the cut took at least eight separate changes across page delivery, retrieval, hydration and ad scoring, so there is no single ticket to schedule.
- Who has to decide decision Before copying request hedging, a team has to confirm the call is a read, because duplicated writes need idempotency keys first.
Uber's own engineers called the old search untenable [1]. The post's claim is that no single change saved more than about 200 ms, and some saved twenty [2]. This account comes from a DEV Community summary of the post Uber Engineering published in September 2026 [3]. The summary does not give a baseline latency in absolute milliseconds, so the list cannot be checked against the halving.
The summary puts figures on eight savings [18]. Added as if each were exact, they come to about 685 ms [17], and the first-page change is about 29% of that [19]. The total is loose. Several figures are "more than" floors, and savings on parallel paths do not add.
Hedging has the clearest conditions. A search fans out to many shards and is only as fast as the slowest one [15]. If a shard misses a time limit, Uber sends the same request to another copy and takes whichever answer comes back first [12]. The post says this works because the stalls were isolated, one shard at a time [12]. It is safe because hydration only reads [13]. We'd expect it to backfire where slow shards are slow from overload, since the duplicate request adds load. The post's case covers the isolated stall only.
Most of the other fixes remove work a later stage never used. Ranking no longer waits for prices it never reads [10]. The catalog is fetched once per product, and grouped that way it is roughly 100 times smaller [9]. Ad scoring reads one field across every bid, so Uber stores bids as columns [14]. Each of these needs someone to trace which fields the next stage actually reads. That tracing is the adoption cost.
For the numbers to transfer, a pipeline needs fan-out across shards and stages that fetch more than the next stage reads. The measurement change needs neither. In our view it is the part to copy first, because the new clock is what pointed Uber at the first-page fix [16].
What to watch
- Whether Uber Engineering's own post gives baseline and final latencies in absolute milliseconds, so the list can be checked against the halving.
- Whether Uber reports how much extra shard load request hedging adds when stalls are not isolated.
- Whether the full post lists further changes after the ad-auction fixes.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption
- Not scored
- Hype gap+8
- Incentives30
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Uber Eats search had gotten so slow that Uber's own engineers called it untenable; Uber then cut the wait in half.
- [2]
No single change saved more than about 200 milliseconds; some saved twenty.
- [3]
Uber Engineering published every change behind the speedup in September 2026.
- [4]
Uber's metric is above the fold: from the moment the user taps search to the moment the first screen of results is fully drawn, images included.
- [5]
The above-the-fold clock counts things the server timer never saw: sending results over the network, building the cards, and loading the photos.
- [6]
The server was building every result, one card at a time, before sending any of them.
- [7]
Uber now sends a small first page and keeps the rest cached on the server for when the user scrolls, and the cards render at the same time instead of one by one; together, the two changes made the first screen appear more than 200 ms sooner, the biggest single win.
- [8]
Retrieval ran several search strategies side by side and merged the results; several broad word-matching strategies were slow and added little the others had not found, and removing them saved about 120 ms by deleting code.
- [9]
Grouped by the product underneath, the catalog is roughly 100 times smaller, and fetching data once per product cut lookups by more than 100 times, saving about 50 ms.
- [10]
Uber split hydration in two: ranking hydration fetches only what scoring needs, while presentation hydration fetches display details in parallel; ranking no longer waits for prices it never reads, which was worth more than 100 ms.
- [11]
Removing false dependencies between steps, where one step waited on another it did not actually need, saved about 35 ms more.
- [12]
Request hedging: if a shard has not answered within a time limit, Uber sends the same request to another copy and takes whichever answer comes back first. It works because the stalls were isolated, one shard at a time, and it saved 40 ms.
- [13]
Hedging is safe here because hydration only reads; sending a payment twice charges twice, so writes need idempotency keys.
- [14]
Scoring in the ad auction reads one field across every bid, so Uber stored the bids as columns and moved campaign and pacing data into the ad service's own memory; ad selection got about 30 ms faster and bid preparation about 110 ms.
- [15]
One search fans out to many machines at once, each holding one slice of the data called a shard, and the answer is only as fast as the slowest shard.
- [16]
The above-the-fold clock pointed straight at the first fix, the first-page change.
- [17]
The eight listed savings add up to about 685 ms if each figure is taken as exact.
- [18]
The summary lists eight separate savings with figures.
- [19]
The first-page change is about 29% of the 685 ms listed total.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toHow Uber Eats Halved Search Time With No Big Fix
1 article · October 16, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.