How to Implement Global Rate Limiting in Spring Boot with Redis and MySQL

Background

In high‑concurrency environments, a global rate‑limiting mechanism is required to protect downstream resources across all instances of a service cluster.

Architecture

The design combines Redis as an in‑memory store for fast read/write of rate‑limit configuration and counters, while MySQL holds the persistent configuration data. The request flow is:

HTTP request enters a Spring Boot application.

A Spring Boot filter intercepts the request.

The filter queries Redis for the limit and current count associated with the target API and the caller’s appId.

If the count is below the limit, the request proceeds and the counter is atomically incremented; otherwise the request is rejected.

Configuration changes are persisted to MySQL and refreshed in Redis without restarting services.

Request Interception (Spring Boot Filter)

The filter extracts the API identifier (e.g., URI) and the business identifier appId. It constructs two Redis hash keys:

{api}_limit – hash where field = appId, value = allowed request count.

{api}_count – hash where field = appId, value = current request count.

Typical Redis operations are HGET to read the limit, HGET to read the current count, and HINCRBY to increment the counter atomically.

Redis Key Design

Two keys are defined per API (or URL):

{api}_limit – map where the field is the appId and the value is the configured limit.

{api}_count – map where the field is the appId and the value is the current request counter.

Dynamic Configuration Management

Configuration APIs or UI components allow adding, updating, or deleting entries in the {api}_limit hash. Changes are written to MySQL and immediately reflected in Redis, enabling real‑time adjustments without service downtime. The three operations are illustrated below:

Add: insert a new appId field with its limit into the hash.

Update: modify the limit value for an existing appId field.

Delete: remove the appId field from the hash.

Conclusion

Leveraging Redis for fast read/write of limit settings and counters, together with MySQL for durable configuration storage, provides a low‑latency global rate‑limiting solution that can be adjusted dynamically with minimal impact on overall system performance.