Your Node.js Gateway It's Doing Twice the Work

You launch a new product. Thousands of users click the same link at the same time. The cache is cold, and your Node.js app starts generating the exact same response hundreds of times simultaneously, burning CPU, hammering your database, and slowing down for everyone. This is the thundering herd problem, and most teams only discover it the hard way. So what if your gateway could just... not do that?

In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina are joined by Paolo Insogna, Principal Software Engineer at Platformatic and Node.js TSC member, to break down how request deduplication works at the gateway level and why it changes the way you think about traffic spikes in Node.js. From the leader/waiter model to distributed coordination with Valkey, Paolo walks through exactly how Platformatic Gateway stops duplicate in-flight requests from reaching your upstream services, without touching a single line of your app code.

In this episode, we cover:

✅ What the thundering herd problem actually is, and why caching alone doesn't solve it

✅ How gateway request deduplication works: the leader/waiter model explained in plain terms

✅ Memory vs. Valkey: when single-instance deduplication is enough and when you need distributed coordination

✅ The metrics that prove it's working, and what to watch for when rolling it out in production

The takeaway?

Caching protects you from future requests. Deduplication protects you while the first response is still being generated. They solve different problems, and running without both means your app is one viral moment away from a very bad day. Paolo built this into Platformatic Gateway so you get the protection without changing your backend, and this episode shows you exactly how it works.