Microservices vs Monolith: Why Rate Limiting Comes Down to Shared State

A software engineering team facing API latency spikes during traffic surges began evaluating whether their rate limiter should live inside their existing monolith or be extracted into a microservice. In a monolith, rate-limiting state can be stored in memory since all requests run through the same process, making enforcement straightforward. However, in a microservices architecture, each independently scaled instance maintains its own in-memory counter, causing the effective rate limit to multiply with every additional instance. The recommended solution is to centralize the shared counter in a fast external datastore such as Redis, which all service instances consult before processing a request. This approach ensures exact limit enforcement regardless of scale, delivers sub-millisecond latency, and simplifies monitoring and tuning to a single location.