How Booking.com cut Node.js costs by 38% with Watt

Booking.com has published a case study on how it runs Node.js at scale with Watt, and the headline number is a 38% cut in compute costs. The company says the win came from reconfiguring its main Node.js rendering service, not from new hardware or code changes. That matters, because this was not a rewrite dressed up as an efficiency story.

The setup shift was simple in concept and quite sharp in effect. Booking moved from pm2’s cluster module to Watt’s worker threads, where each worker takes connections straight from the kernel with SO_REUSEPORT instead of pushing every request through a supervisor over IPC. One less hop in the request path sounds modest until you’re under load. In mixed-workload tests, Booking says the new setup handled 40% to 50% more requests while still hitting its latency SLO.

There was a catch, though. With SO_REUSEPORT, the kernel hashes connection addresses and ports to pick a worker, and loopback reuse can make that assignment lopsided. Booking saw some workers running as much as 40% hotter than others, depending on the workload. The workaround was to stop fighting the kernel and let nginx do the balancing instead: each worker listened on its own port, nginx spread traffic with round robin, and one service even split render-heavy and lightweight endpoints with a 4+1 setup using least_conn.

Watt supports that mode through its portAssignment perWorkerIncrement setting. Booking also used the extra headroom to tune V8 garbage collection, and it ran the whole thing as a proper A/B production trial: two full installations side by side, same number of pods, same resources, traffic split at routing level. The result it reports is specific and tidy: 30% fewer pods, 20% lower memory use per remaining pod, and latency down by as much as 10% at p75, p99, and p99.9.