Implements API rate limiting and throttling controls using token bucket, sliding window, and fixed window algorithms to protect against brute force attacks, credential stuffing, resource exhaustion, and API abuse. The engineer configures per-user, per-IP, and per-endpoint rate limits using Redis-backed counters, API gateway plugins, or application middleware, and implements proper HTTP 429 responses with Retry-After headers. Activates for requests involving rate limiting implementation, API throttling setup, request quota management, or API abuse prevention.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Implements API rate limiting and throttling controls using token bucket, sliding window, and fixed window algorithms to protect against brute force attacks, credential stuffing, resource exhaustion, and API abuse. The engineer configures per-user, per-IP, and per-endpoint rate limits using Redis-backed counters, API gateway plugins, or application middleware, and implements proper HTTP 429 responses with Retry-After headers. Activates for requests involving rate limiting implementation, API throttling setup, request quota management, or API abuse prevention.
Protecting authentication endpoints against brute force and credential stuffing attacks
Preventing API abuse and resource exhaustion from automated scripts and bots
Implementing fair usage quotas for different API consumer tiers (free, premium, enterprise)
Defending against denial-of-service attacks at the application layer
Meeting compliance requirements that mandate API abuse prevention controls
Do not use rate limiting as the sole defense against attacks. Combine with authentication, authorization, and WAF rules.
Common Misconfigurations & Verification
In-memory counters on multi-instance deployments: per-process state lets clients bypass limits by landing on different servers - use shared Redis.
Per-IP only / trusting XFF: spoofable; key by user/API key plus a validated client IP.
Fixed-window seam: allows ~2x bursts at window boundaries; use sliding window or token bucket.
Race conditions: non-atomic check-then-increment overshoots under concurrency - use a Lua script/INCR.
No auth-endpoint tier: login/reset/MFA need stricter limits than general API traffic.
Missing headers/Retry-After: clients can't back off cleanly; always emit X-RateLimit-* and Retry-After on 429.
How to verify it works: load-test past the limit and confirm 429 + Retry-After at the right count; run against all instances to prove shared enforcement; rotate X-Forwarded-For to confirm no reset; send concurrent bursts to confirm no race overshoot; kill Redis and confirm the chosen fail-open/closed behavior.
Prerequisites
Redis 6.0+ for distributed rate limit counters (or in-memory for single-instance deployments)
API framework (Express.js, FastAPI, Spring Boot, or Django REST Framework)
Monitoring system for rate limit metrics (Prometheus, CloudWatch, Datadog)
Understanding of the API's normal traffic patterns and peak usage
Load testing tool (k6, Gatling, or Locust) for validating rate limit behavior
Workflow
Step 1: Rate Limiting Strategy Design
Define rate limits per endpoint category and user tier:
Step 5: Distributed Rate Limiting for Microservices
# Centralized rate limiting service using Redis Clusterimport redis
from redis.cluster import RedisCluster
classDistributedRateLimiter:
"""Rate limiter for microservice architectures using Redis Cluster."""def__init__(self):
self.redis = RedisCluster(
startup_nodes=[
{"host": "redis-node-1", "port": 6379},
{"host": "redis-node-2", "port": 6379},
{"host": "redis-node-3", "port": 6379},
],
decode_responses=True
)
defcheck_and_increment(self, service_name, user_id, endpoint,
max_requests, window_seconds):
"""Atomic check-and-increment using Redis Lua script."""
key = f"rl:{{{service_name}}}:{user_id}:{endpoint}"# Lua script ensures atomicity across the check and increment
lua_script = """
local key = KEYS[1]
local max_requests = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local window_start = now - window
-- Remove old entries
redis.call('zremrangebyscore', key, '-inf', window_start)
-- Count current entries
local count = redis.call('zcard', key)
if count >= max_requests then
-- Get oldest entry for retry-after calculation
local oldest = redis.call('zrange', key, 0, 0, 'WITHSCORES')
local retry_after = 0
if #oldest > 0 then
retry_after = math.ceil(tonumber(oldest[2]) + window - now)
end
return {0, count, retry_after}
end
-- Add new entry
redis.call('zadd', key, now, now .. ':' .. math.random(100000))
redis.call('expire', key, window + 1)
return {1, count + 1, 0}
"""
result = self.redis.eval(lua_script, 1, key,
max_requests, window_seconds, time.time())
return {
"allowed": bool(result[0]),
"current": int(result[1]),
"retry_after": int(result[2]),
}
Key Concepts
Term
Definition
Sliding Window
Rate limiting algorithm that tracks requests in a rolling time window, providing smoother rate enforcement than fixed windows
Token Bucket
Algorithm where tokens are added at a fixed rate and consumed per request, allowing controlled bursts up to the bucket capacity
Fixed Window
Simplest rate limiting where requests are counted per fixed time window (e.g., per minute), susceptible to burst at window boundaries
429 Too Many Requests
HTTP status code indicating the client has exceeded the rate limit, accompanied by Retry-After header
Retry-After Header
HTTP response header telling the client how many seconds to wait before retrying, essential for well-behaved API clients
Distributed Rate Limiting
Rate limiting across multiple server instances using shared state (Redis, Memcached) to maintain accurate global counters
Tools & Systems
Redis: In-memory data store used for distributed rate limit counters with atomic operations via Lua scripts
Kong Rate Limiting Plugin: API gateway plugin supporting fixed-window and sliding-window rate limiting with Redis backend
express-rate-limit: Express.js middleware for simple rate limiting with Redis, Memcached, or in-memory stores
Flask-Limiter: Flask extension for rate limiting with support for multiple backends and configurable limits per endpoint
Envoy Rate Limit Service: Centralized rate limiting service for Envoy-based service mesh architectures
Common Scenarios
Scenario: Implementing Rate Limiting for a Public API
Context: A company launches a public API with free, premium, and enterprise tiers. The API must protect against abuse while providing fair access to paying customers. The API runs on 6 instances behind an AWS ALB.
Approach:
Deploy Redis Cluster (3 nodes) for distributed rate limit state
Implement sliding window rate limiter using Redis sorted sets with Lua scripts for atomicity
