Module 4 · Rate Limiting & API Abuse Prevention 🔒

Rate limiting is the operational defense that prevents APIs from being abused at scale. Without it, every authenticated endpoint is a potential cost-amplifier (cloud bills), brute-force vector (auth endpoints), or DoS surface. With well-designed rate limits, abusive patterns hit walls quickly while legitimate traffic flows. This module covers rate-limit design, abuse patterns, and the architectures that scale.

Why “set a rate limit” isn’t enough

The naive answer — “100 requests per second per IP” — fails in three common cases:

• NAT-shared IPs — entire offices and ISPs come from one IP. Rate-limiting per IP punishes legitimate clusters
• Distributed abuse — attacker uses 10,000 IPs at 1 request each. Per-IP limit useless
• Asymmetric expense — 100 cheap requests per second is fine; 100 expensive aggregations per second melts the database

Rate limiting needs to be multi-dimensional and aware of cost.

Dimensions to rate-limit on

• Per-user / per-tenant — primary axis. Authenticated traffic gets per-account limits. Anonymous gets per-IP fallback
• Per-IP — secondary; useful for unauthenticated endpoints and as anti-distributed-abuse layer
• Per-endpoint — different limits for different costs (10K req/min for /search, 5 req/min for /reset-password)
• Per-action category — auth attempts, write operations, expensive reads each tracked
• Per-API-key — for external developers; tier’d by plan
• Cost-weighted — each request consumes a “cost” from the user’s budget; cheap reads = 1, expensive aggregations = 100

Algorithms — what to actually implement

Fixed window counter

“100 requests per minute” with the minute being a fixed clock minute. Simple. Edge case: bursting at the boundary lets attacker do 200 in 2 seconds (last second of minute N + first second of minute N+1).

Sliding window log

Track timestamp of every request; count those in the last 60 seconds. Accurate but memory-heavy.