Making Amazon Search faster

A one-year program that turned dozens of experiments, strategic platform investments, and operational rigor into faster search for customers worldwide.

Team Size

1 year

Timeline

Goals Met

zero

Downtime

Context

Every millisecond matters

Amazon Search is the last mile between a customer's query and the product they want to buy. A9 returned a ranked set of ASINs; our systems fetched the product details, decorated the results, and rendered the page customers saw.

That responsibility spanned a complex, multi-team codebase serving mobile and desktop experiences across 14 marketplaces. Improvements had immediate reach, but any mistake could affect sales, engagement, or availability at enormous scale.

Search was often where customers decided whether a product was worth a closer look. To support that decision, the search page assembled hundreds of product attributes, promotion details, images, and other information from dozens of systems before rendering the results. More information helped customers make better choices, but each additional data source and visual element introduced work that could slow the page down. The challenge was to provide a useful, information-rich experience without making customers wait for it.

At Amazon's scale, every millisecond mattered. A delay of as little as 100 milliseconds could reduce customer engagement and the likelihood that customers would continue exploring the site. Latency was therefore more than a technical performance metric. It was part of the customer experience and had a direct relationship to how people searched, evaluated products, and ultimately decided whether to buy.

The Challenge

A goal the organization had missed for four years

The mandate was simple: reduce p50 and p90 above-the-fold (ATF) latency by 10% everywhere
And do it with zero self-inflicted downtime

Distributed latency

Customer connections varied widely, and a search page depended on dozens of systems that could slow down or fail. For each dependency, we had to decide whether retrying would improve the experience or simply make the customer wait longer, and when omitting information was the better choice. There was no single bottleneck to remove, so the team had to investigate less obvious opportunities across the full request and rendering path.

Commercial guardrails

A change could make the page faster and still make the customer experience worse. Reducing the amount of information, changing how it appeared, or loading it differently could affect both sales and customer satisfaction. We measured every experiment against those outcomes and only accepted changes that had a neutral or positive effect on the business.

Shared ownership

Search-page display logic spanned several independent teams working in a large, complex codebase. Merge conflicts, review dependencies, and overlapping releases could slow delivery even when the optimization itself was straightforward. We also had to monitor changes from other teams that might increase latency and negotiate feature priorities when they competed with the performance goals.

Peak-scale reliability

Performance improvements could not come at the expense of availability, so every change required rigorous testing, monitoring, and a safe rollout plan. Q4 preparation compressed the time available for development through code freezes, hardware provisioning, load testing, and game-day exercises. Those demands shortened our effective delivery window while adding operational pressure to the team.

How I Led

Turning a target into an organizational program

Previous attempts to improve latency had been largely ad hoc. Teams pursued promising ideas, but there was no consistent rhythm for reviewing results, coordinating experiments, or connecting individual changes to the annual goal. I formalized the work as an ongoing program with clear ownership and a regular review process.

The team reviewed latency metrics every week. We ran experiments in a controlled sequence so that overlapping changes did not create cross-talk or make the results difficult to interpret. Shared dashboards gave everyone the same view of performance, with the annual targets displayed alongside markers showing when each experiment started and stopped.

We also maintained a backlog of potential experiments and revisited its priorities regularly. The team focused first on the ideas we believed could have the greatest effect, then used the weekly reviews to decide whether to expand, revise, or remove each change. This gave us a repeatable way to turn individual optimizations into measurable progress against the larger goal.

A shared source of truth

Dedicated dashboards tracked p50 and p90 ATF latency by marketplace and device so the team could see progress and regressions clearly and were distributed to senior leadership so they could check goal progress at any time.

Standards for experiments

I established timeboxes, dial-up and dial-down procedures, success criteria, and guardrails for sales and customer engagement to be used when conducting each experiment.

Close every loop

Failed experiments were removed; successful ones were made permanent. Every launch had a named owner and an explicit end state. This established ownership and kept the legacy codebase clean and maintained.

Make progress legible

Regular senior-leadership reporting connected individual changes to the annual goal and kept a C-suite-visible program grounded in evidence.

Performance stopped being a periodic push and became a program: measured continuously, reviewed regularly, and owned through completion.

Key Decisions

Small wins, platform shifts, and a longer bet

We divided the development work into three pillars with different time horizons and levels of risk. The first was a steady stream of small experiments that the team could implement and validate quickly. No single change needed to transform the page on its own. The aim was to remove latency wherever we found it, knowing that enough modest improvements would add up to a meaningful result.

The second pillar covered required platform migrations. We had commitments to remove our dependencies on services owned by other teams so they could retire aging systems. The replacement platforms were faster and provided richer product data. Although these migrations did not begin as latency projects, we treated their performance characteristics as part of the design and used the work to support both our goals and the broader needs of the organization.

The third pillar was a larger greenfield investment in predictive latency. Working with our data scientists, we built infrastructure that estimated expected client performance and adjusted the customer experience accordingly. The prediction also became a hint that other parts of the system could use when deciding how much content to load or how to present it. This gave us a substantial latency improvement while creating a capability that extended beyond the original project.

Controlled experiments

A high-volume pipeline of focused enhancements, A/B tested for latency improvement and commercial safety.

DNS prefetch optimization
Prefetching the next results page
Predictive result prefetch from search history
Image quality and progressive loading

DataPath migration

Moved product-description decorations onto the new DataPath platform, improving latency while enabling richer product details.

Retired architectural debt
Reduced decoration latency
Created a stronger product foundation

Predictive latency

Fingerprint browser and connection characteristics, estimate expected latency, and serve scaled-down visuals when conditions demand it.

Greenfield system
Adaptive customer experience
US Patent 10,796,079 B1

Outcomes

Four years of misses. Then every target met

14 / 14

Marketplaces impacted

p90 / p50

Measurements met

zero

Self-inflicted downtime minutes

75 - 125ms

Improvement in p50 latency

200 – 400ms

Improvement in p90 latency

More than 20 enhancements evaluated through controlled A/B tests

DataPath delivered faster, richer product-description decorations

Predictive latency remains in production and earned a US patent

Scaling, load testing, and operational readiness completed ahead of Q4 peak

Reflection

What I carried forward

Large performance goals are rarely won by a single breakthrough. They are won by creating a system that can discover, validate, compound, and sustain improvements without losing sight of the customer.

Ownership changes everything

Engineers build better products when they genuinely feel responsible for the outcome.

Slow and steady wins

Big lift projects are exciting, but may not be the best solution.

Leave the code better than you found it

Cleaning up as you go will pay dividends, especially in a multi-team distributed codebase.

See the forest for the trees

Focusing on the goal is good, but always consider unintended side-effects.