Rate Limiting & Throttling 🚦

Protect your API from abuse with token bucket rate limiting, sliding windows, IP controls, and Redis-backed distributed throttling.

What You'll Learn in This Lesson

• Why rate limiting is essential for API security
• Token bucket algorithm implementation
• Per-user, per-endpoint, and per-IP limiting
• Sliding window vs fixed window trade-offs
• Redis-backed distributed rate limiting

Note: PHP runs on a server. Our examples simulate PHP logic using JavaScript. To run real PHP, install PHP.

🎯 Real-World Analogy: Rate limiting is like a bouncer at a club. The club has a capacity (limit). Once it's full, new people wait outside (429 response). VIP members (allowlisted IPs) skip the line. Known troublemakers (blocklisted IPs) are turned away permanently. The token bucket is like drink tickets — you get 5 per hour, use them at your pace, and they refill over time.

Token Bucket Rate Limiter

The token bucket algorithm is the most popular rate limiting approach. Each client has a bucket of tokens that refills at a constant rate. Each request consumes one token. When the bucket is empty, requests are denied until tokens refill — allowing short bursts while enforcing long-term limits.

Try It: Token Bucket

Build a rate limiter with capacity, refill rate, and response headers

Try it Yourself »

JavaScript

// Building a Rate Limiter
console.log("=== Why Rate Limit? ===");
console.log();
console.log("Without limits, a single client can:");
console.log("  • Crash your server with thousands of requests");
console.log("  • Brute-force passwords by trying millions of combinations");
console.log("  • Scrape your entire database through the API");
console.log("  • Rack up massive server costs");
console.log();

console.log("=== Token Bucket Algorithm ===");
console.log();
console.log("Imagine a bucket th
...

Advanced Strategies

Production APIs need different limits for different endpoints — login attempts are stricter than search queries. Use sliding windows for smoother rate enforcement, IP blocklists for known bad actors, and Redis for rate limiting across multiple servers.

Try It: Advanced Rate Limiting

Per-endpoint limits, sliding windows, IP controls, and Redis implementation

Try it Yourself »

JavaScript

// Advanced Rate Limiting Strategies
console.log("=== Per-User vs Per-IP Limiting ===");
console.log();

class RateLimiterStore {
  constructor() { this.windows = new Map(); }

  check(key, limit, windowSec) {
    let now = Date.now();
    let windowKey = key + ":" + Math.floor(now / (windowSec * 1000));
    let count = this.windows.get(windowKey) || 0;
    count++;
    this.windows.set(windowKey, count);
    
    return {
      allowed: count <= limit,
      count: count,
      limit: limit,
  
...

⚠️ Common Mistakes

⚠️

Rate limiting only by IP — multiple users behind a corporate NAT share one IP. Rate limit by authenticated user ID when possible, fall back to IP for anonymous requests.

⚠️

No Retry-After header — when you return 429, always include Retry-After so clients know when to try again instead of hammering your server.

💡

Pro Tip: Apply stricter limits to write endpoints (POST, PUT, DELETE) than read endpoints (GET). A bot scraping data is annoying; a bot creating thousands of accounts is dangerous.

📋 Quick Reference — Rate Limiting

Algorithm	Best For
Token Bucket	Allows bursts, smooth long-term rate
Fixed Window	Simple, resets at interval boundaries
Sliding Window	Smooth, no burst at boundary
Leaky Bucket	Constant output rate, queues bursts

🎉 Lesson Complete!

Your APIs are now protected! Next, learn to offload heavy work with background queues and message brokers.