Uber Eats Rebuilds Search Pipeline, Halves End-to-End Latency

Uber has overhauled large sections of the search pipeline behind Uber Eats, the company says, cutting end-to-end latency by half. The work, detailed by Leela Kumili, targeted nearly every stage a query passes through — from the point a user starts typing to the moment results and ads render. For a marketplace where hungry users abandon slow sessions quickly, halving that response time is a direct hit on conversion, not just an engineering vanity metric.

The team rethought how it measures success before it changed any code. It adopted an Above-the-Fold metric, which tracks how quickly the results a user can actually see without scrolling become available. That shift matters because traditional end-to-end timings lump together work the user never notices with the work that decides whether the page feels fast. Optimizing against visible content gave engineers a truer target.

On retrieval, Uber trimmed the amount of work performed per query, cutting back the candidate set pulled before ranking begins. Hydration — the step that fills in details like menus, prices and store status — was parallelized so independent lookups no longer queue behind one another. The ads data path also got a redesign, separating ad fetching from the core result flow so advertising logic stops gating organic results.

Infrastructure changes ran alongside the application work, and Uber credits an agentic coding workflow with helping move the project faster. That phrase points to AI agents handling chunks of routine implementation and refactoring under human review, a pattern more engineering orgs are testing on large legacy systems. Uber has not published how much of the code those agents wrote or how review overhead balanced against the speed gained.

The company isn't stopping at the 50% mark. Uber says it is exploring microbatching to group nearby requests, product-based retrieval that organizes candidates by item rather than store, and HTTP multipart streaming to push partial results to the client as they arrive. Each of those attacks a different bottleneck: batching cuts per-request overhead, product retrieval narrows the search space, and streaming hides server-side tail latency behind incremental rendering.

The open question is how much of this translates outside Uber's scale. Techniques like Above-the-Fold measurement and parallel hydration are broadly applicable, but the payoff depends on how a given company's search stack is wired and how much ads revenue shares the critical path. If Uber publishes latency numbers after microbatching and streaming land, the industry will get a clearer read on where the remaining gains actually live.