How Do We Scale Rate Limiting in Node.js?

Your Node.js service has rate limiting. You tested it, it worked, you shipped it. But your limit lives in the memory of a single process, and the moment you run more than one instance behind a load balancer, every replica enforces its own private budget. Ten instances means ten times the traffic you thought you were allowing. That is not a smaller problem at scale, it is a different problem entirely. So what does rate limiting that actually holds across a cluster look like? In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dig into rate limiting for Node.js applications, why the obvious approach quietly fails in production, and how to build limits that survive horizontal scaling. In this episode, we cover: ✅ The mechanics of in-process rate limiting and the trap of the in-memory store. ✅ Why per-instance counters cannot enforce a global limit once you scale out. ✅ How to back rate limiting with a shared store like Redis or Valkey, and the patterns that actually work. ✅ The operational realities: clock skew across nodes, what happens when your shared store goes down, and the consistency-versus-performance balance you have to choose. The takeaway? A rate limit is a promise about your whole system, not one process. If it only holds on a single instance, it is lying to you. Get distributed rate limiting right, and Node.js handles abuse and traffic spikes gracefully. Get it wrong, and you will find out the hard way, in production, under load.