การจำกัดอัตราการส่งคำขอแบบกระจายด้วย Redis

When you run several gateway replicas, each one keeping its own in-memory counter means a client gets N x limit total — once per instance.

To enforce one global limit, every instance must read and update shared state.

Redis is the de facto choice for distributed rate limiting because it offers:

• Sub-millisecond in-memory reads and writes
• Atomic commands like INCR
• Built-in expiry for automatic window resets
• Lua scripting for multi-step atomic logic

The simplest fixed-window counter uses INCR plus EXPIRE:

The first request in a window creates the key and sets a TTL; later requests just increment.

Running INCR then EXPIRE as two separate calls has a bug: if the process crashes between them, the key has no TTL and the limit never resets.

The fix is to make the check-and-increment atomic.

Redis runs a Lua script as a single atomic unit. We can check the count, increment, and set expiry without interruption.

From the gateway you invoke the script with EVAL, passing the key, the limit, and the window size.

A return of 1 means allow; 0 means reject with 429 Too Many Requests.

For smoother limiting, store request timestamps in a sorted set. Remove old entries, count what remains, then add the new one.

Good gateways tell clients where they stand using standard headers:

• X-RateLimit-Limit
• X-RateLimit-Remaining
• Retry-After on a 429

The Lua script can return remaining count alongside the allow flag.

What if Redis is unreachable? Two strategies:

• Fail open — allow traffic; favors availability
• Fail closed — reject traffic; favors protection

Most APIs fail open with a local fallback limiter to avoid a full outage.

Every limit check is a network hop. Cut overhead by:

• Co-locating Redis near the gateway
• Using connection pooling
• Batching counters with a short local cache for very hot keys

The rate limit key defines what you are limiting. Common choices:

• rate:ip:1.2.3.4 for anonymous traffic
• rate:user:42 for authenticated users
• rate:apikey:abc for API clients

Pick the most specific identity available so one abuser cannot exhaust a shared bucket.

You learned to share rate limit state across instances:

• A shared Redis store gives one global limit
• Lua scripts make check-and-increment atomic
• Sorted sets enable sliding windows
• Decide fail open vs. closed for Redis outages