Booking.com Cuts Compute Costs 38% by Tuning Its Largest Node.js Service

Booking.com's engineers report a 38% compute saving on their biggest Node.js service, offering a rare look at how the platform renders its pages.

By optimizing the service, the team ran 30% fewer pods, reduced memory use by 20% per remaining pod, and took up to 10% off latency at p75, p99 and beyond. There was no new hardware and no change to the service's own code; the gains came from Node.js platform changes and a fresh look at configuration choices left untouched for years.

Architecture context

• In 2025, 1.2 billion room nights were booked across Booking Holdings.
• The back end mixes Java, Perl, Rust and Node.js; Node handles server-side rendering, some data APIs and tooling.
• Pages are server-rendered so they work without client-side JavaScript and can be crawled. React server rendering is CPU-bound, so throughput depends on how many cores stay busy.
• Each major page (home, search results, property) has its own Node rendering service owned by that page's team, assembled from sections owned by other teams.
• The setup stems from migrating off Perl one fragment at a time, each swap behind an experiment.
• Some components load at runtime through Webpack Module Federation, so a team can ship an update, such as a new header, to all rendering services within minutes.
• Full-page renders take 100 to 400ms and are dominated by CPU-blocking work; calls to the /metadata endpoint usually finish in under 30 to 50ms.