--- title: How Booking.com cut Node.js costs by 38% with Watt description: Booking.com published a case study detailing how migrating their main Node.js rendering service from pm2 to Platformatic's Watt cut compute costs by 38%, using... canonical: https://daily.dev/posts/how-booking-com-cut-node-js-costs-by-38-with-watt-tbbnjyj52 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: How Booking.com cut Node.js costs by 38% with Watt | daily.dev og:description: Booking.com published a case study detailing how migrating their main Node.js rendering service from pm2 to Platformatic's Watt cut compute costs by 38%, using... og:url: https://daily.dev/posts/how-booking-com-cut-node-js-costs-by-38-with-watt-tbbnjyj52 og:image: https://api.daily.dev/og/posts/tbbNjYj52.png og:image:alt: How Booking.com cut Node.js costs by 38% with Watt og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # How Booking.com cut Node.js costs by 38% with Watt **[Adventures in Nodeland](https://daily.dev/sources/nodeland)** · 4 min read · 74 upvotes · 12 comments ## Summary Booking.com published a case study detailing how migrating their main Node.js rendering service from pm2 to Platformatic's Watt cut compute costs by 38%, using 30% fewer pods and 20% less memory per pod, while lowering latency by up to 10% at the p75, p99, and p99.9 levels. The migration replaced pm2's cluster module and IPC-based supervisor with Watt's worker threads, where each worker accepts kernel connections directly via SO_REUSEPORT, removing a network hop. To fix uneven load distribution caused by SO_REUSEPORT's connection hashing, Booking.com had each worker listen on its own port and let their existing nginx handle load balancing via round robin or least_conn, supported by Watt's portAssignment perWorkerIncrement config. Watt also automatically restarts threads that block the event loop. The test was run as an A/B production trial with identical pod counts and resources on both sides, with extra headroom used to tune V8 garbage collection. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How did Booking.com reduce Node.js infrastructure costs by migrating from pm2 to Watt? Booking.com cut Node.js compute costs by 38% by switching their main rendering service from pm2's cluster module to Platformatic Watt's worker threads. They ran 30% fewer pods, used 20% less memory per pod, and lowered latency by up to 10% at p75, p99, and p99.9, without changing service code or adding hardware. _Teams weighing a pm2-to-watt migration can compare real production cost benchmarks like this on daily.dev._ ### Why does SO_REUSEPORT cause uneven load distribution across Node.js worker threads? SO_REUSEPORT assigns connections to workers by hashing the connection's source and destination addresses and ports; because tcp_tw_reuse lets loopback connections be reused, that hash often routes repeat traffic to the same worker, leaving some threads up to 40% busier than others. Booking.com fixed this by having each worker listen on a separate port and letting nginx load-balance in front using round robin or least_conn. _Engineers debugging uneven worker load in Node.js clusters can track SO_REUSEPORT gotchas like this on daily.dev._ ### What load balancing strategy did Booking.com use with Watt's portAssignment feature? Booking.com configured Watt's portAssignment with perWorkerIncrement so each worker listens on its own port, then relied on an existing nginx layer for load balancing instead of kernel-level SO_REUSEPORT hashing. They used round robin generally, and for one service split render-intensive and lightweight endpoints across separate workers (a 4+1 split) using least_conn to reclaim a few percent of tail latency. _Developers tuning Node.js worker load balancing can reference configurations like this on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@pdfopsdev** · 11 upvotes > the SO_REUSEPORT hashing quirk is the part people will skip past. without nginx actually doing round robin in front, raw SO_REUSEPORT fanout can starve workers under skewed connection patterns, so that per-worker port assignment is carrying more of the win than the 38% headline suggests. **@ajaychoudhary80** · 9 upvotes > The interesting part isn’t just switching from pm2 to Watt—it’s how they combined worker threads with nginx load balancing to solve SO_REUSEPORT’s uneven distribution. **@cloudcomputing6** · 6 upvotes > **A great example of how runtime architecture can translate directly into infrastructure savings. 38% lower compute cost is a serious win.** **@ristotoldsep** · 2 upvotes > 38% cheaper by deleting an IPC hop. performance work still pays real invoices. **@kelvin\_lima** · 1 upvotes > Solid case study. Cutting compute costs by 38% just by tweaking the threading and routing setup is huge. ## Similar posts on daily.dev - [Accelerate Next.js in Kubernetes](https://daily.dev/posts/accelerate-next-js-in-kubernetes-3j9rdkr9z) · Platformatic · 5 upvotes · 0 comments - [Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers](https://daily.dev/posts/modular-edge-computing-at-multi-tenant-saas-scale-on-cloudflare-workers-zgtnvgdda) · InfoQ · 0 upvotes · 0 comments - [Node.js CPU and Heap Profiling with Shareable Flame Graphs](https://daily.dev/posts/node-js-cpu-and-heap-profiling-with-shareable-flame-graphs-q11btrkcn) · Platformatic · 35 upvotes · 0 comments - [The MonkCast: WASM and Edge Compute](https://daily.dev/posts/the-monkcast-wasm-and-edge-compute-hk6um3xpj) · Fermyon · 1 upvotes · 0 comments - [Node.js Hosting Options](https://daily.dev/posts/node-js-hosting-options-3kxkbxmd7) · RUBYLAND · 0 upvotes · 0 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#nodejs](https://daily.dev/tags/nodejs) [View this post on daily.dev](https://daily.dev/posts/how-booking-com-cut-node-js-costs-by-38-with-watt-tbbnjyj52) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"How Booking.com cut Node.js costs by 38% with Watt","url":"https://daily.dev/posts/how-booking-com-cut-node-js-costs-by-38-with-watt-tbbnjyj52","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/how-booking-com-cut-node-js-costs-by-38-with-watt-tbbnjyj52"},"datePublished":"2026-10-05T10:08:46.097Z","dateModified":"2026-10-05T10:09:12.351Z","description":"Booking.com published a case study detailing how migrating their main Node.js rendering service from pm2 to Platformatic's Watt cut compute costs by 38%, using...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/825b8ae5d8b786796324258dde947b6a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/825b8ae5d8b786796324258dde947b6a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Adventures in Nodeland","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Adventures in Nodeland","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/4ec40f35e6e440c7ab313b37d0039595","url":"https://daily.dev/sources/nodeland"},"commentCount":12,"discussionUrl":"https://daily.dev/posts/how-booking-com-cut-node-js-costs-by-38-with-watt-tbbnjyj52","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":74},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":12}],"keywords":"performance,nodejs","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Adventures in Nodeland","item":"https://daily.dev/sources/nodeland"},{"@type":"ListItem","position":3,"name":"How Booking.com cut Node.js costs by 38% with Watt"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/how-booking-com-cut-node-js-costs-by-38-with-watt-tbbnjyj52","comment":[{"@type":"Comment","text":"the SO_REUSEPORT hashing quirk is the part people will skip past. without nginx actually doing round robin in front, raw SO_REUSEPORT fanout can starve workers under skewed connection patterns, so that per-worker port assignment is carrying more of the win than the 38% headline suggests.","datePublished":"2026-10-05T18:01:19.935Z","url":"https://daily.dev/posts/tbbNjYj52#c-0dWyk1fu8","author":{"@type":"Person","name":"PDFops","url":"https://daily.dev/pdfopsdev","image":"https://media.daily.dev/image/upload/s---8isRBKc--/f_auto/v1782922291/avatars/avatar_orjMeK8QKaaVZwGq7ScPz?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":11}},{"@type":"Comment","text":"The interesting part isn’t just switching from pm2 to Watt—it’s how they combined worker threads with nginx load balancing to solve SO_REUSEPORT’s uneven distribution.","datePublished":"2026-10-06T03:17:53.957Z","url":"https://daily.dev/posts/tbbNjYj52#c-uvGs9FYOY","author":{"@type":"Person","name":"Ajay Choudhary","url":"https://daily.dev/ajaychoudhary80","image":"https://media.daily.dev/image/upload/s--WkX8wDW2--/f_auto/v1780989706/avatars/avatar_QNZlI2SgVnNSx5PSRpCVx?_a=BAMAMiWQ0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":9}},{"@type":"Comment","text":"A great example of how runtime architecture can translate directly into infrastructure savings. 38% lower compute cost is a serious win.","datePublished":"2026-10-06T03:17:28.184Z","url":"https://daily.dev/posts/tbbNjYj52#c-HxelFy9oH","author":{"@type":"Person","name":"cloudcomputing","url":"https://daily.dev/cloudcomputing6"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":6}},{"@type":"Comment","text":"38% cheaper by deleting an IPC hop. performance work still pays real invoices.","datePublished":"2026-10-06T10:11:44.286Z","url":"https://daily.dev/posts/tbbNjYj52#c-iTgnkkQHE","author":{"@type":"Person","name":"Risto Tõldsep","url":"https://daily.dev/ristotoldsep","image":"https://lh3.googleusercontent.com/a/ACg8ocLDWc6mZn0JwNmXXw6WY0L_HJ6pegzRttooC5VgtXESHSj3MNYx=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"Solid case study. Cutting compute costs by 38% just by tweaking the threading and routing setup is huge.","datePublished":"2026-10-08T13:50:26.803Z","url":"https://daily.dev/posts/tbbNjYj52#c-h2cypJGbC","author":{"@type":"Person","name":"Kelvin Lima","url":"https://daily.dev/kelvin_lima","image":"https://media.daily.dev/image/upload/s--aETMiQc5--/f_auto/v1787513560/avatars/avatar_asGeTu7mKynRnhXcOxYVt?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/how-booking-com-cut-node-js-costs-by-38-with-watt-tbbnjyj52#faq","mainEntity":[{"@type":"Question","name":"How did Booking.com reduce Node.js infrastructure costs by migrating from pm2 to Watt?","acceptedAnswer":{"@type":"Answer","text":"Booking.com cut Node.js compute costs by 38% by switching their main rendering service from pm2's cluster module to Platformatic Watt's worker threads. They ran 30% fewer pods, used 20% less memory per pod, and lowered latency by up to 10% at p75, p99, and p99.9, without changing service code or adding hardware. Teams weighing a pm2-to-watt migration can compare real production cost benchmarks like this on daily.dev."}},{"@type":"Question","name":"Why does SO_REUSEPORT cause uneven load distribution across Node.js worker threads?","acceptedAnswer":{"@type":"Answer","text":"SO_REUSEPORT assigns connections to workers by hashing the connection's source and destination addresses and ports; because tcp_tw_reuse lets loopback connections be reused, that hash often routes repeat traffic to the same worker, leaving some threads up to 40% busier than others. Booking.com fixed this by having each worker listen on a separate port and letting nginx load-balance in front using round robin or least_conn. Engineers debugging uneven worker load in Node.js clusters can track SO_REUSEPORT gotchas like this on daily.dev."}},{"@type":"Question","name":"What load balancing strategy did Booking.com use with Watt's portAssignment feature?","acceptedAnswer":{"@type":"Answer","text":"Booking.com configured Watt's portAssignment with perWorkerIncrement so each worker listens on its own port, then relied on an existing nginx layer for load balancing instead of kernel-level SO_REUSEPORT hashing. They used round robin generally, and for one service split render-intensive and lightweight endpoints across separate workers (a 4+1 split) using least_conn to reclaim a few percent of tail latency. Developers tuning Node.js worker load balancing can reference configurations like this on daily.dev."}}]} ```