A few years ago, I worked with a developer named Marcus who had just launched a public API for a niche movie database. He was thrilled—until about two hours after the launch. One of his early adopters had written a poorly optimized scraping script that hit the /api/movies/search endpoint in a tight while loop without any delay. Within minutes, the database CPU spiked to 100%, the connection pool exhausted, and the entire site went offline for everyone. Marcus hadn't written a single line of code to limit how often a single user could call his API. He thought his server could handle the load, but no matter how big your server is, a single rogue script can always find a way to choke it.

That's where rate limiting and throttling come in. While people often use these terms interchangeably, they're slightly different. Rate limiting is the hard stop—you tell the user, "You've had enough for this minute; go away." Throttling is more about slowing the user down, perhaps by introducing a delay in the response. In PHP, since we're dealing with a share-nothing architecture where every request starts fresh, we need a fast, external way to keep track of who is calling us and how often.

Why Redis is the Right Tool for the Job

You could technically use a MySQL table to track request counts, but I strongly advise against it. Writing to a disk-based database every single time a request hits your API creates a massive bottleneck—you'd be adding a database write just to decide if you should allow a database read. It's overkill and slow.

Instead, use Redis. It's an in-memory data store, meaning it's incredibly fast, and it has a built-in EXPIRE feature that handles the "reset" part of rate limiting automatically. When we track a user, we don't want to store that record forever; we only care about their request count for the current window of time.

Building a Fixed-Window Limit

The simplest way to implement this is the "Fixed Window" algorithm. We create a key in Redis based on the user's IP address and the current timestamp (rounded to the nearest minute). If the key doesn't exist, we create it with a value of 1 and set it to expire in 60 seconds. If it does exist, we just increment the value.

// A simplified example of a rate limit check
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

$userIp = $_SERVER['REMOTE_ADDR'];
$currentTime = time();
// Create a unique key for this IP for the current minute
$window = floor($currentTime / 60); 
$key = "rate_limit:{$userIp}:{$window}";

$requestCount = $redis->incr($key);

if ($requestCount === 1) {
    // This is the first request in this window, set expiration
    $redis->expire($key, 60);
}

if ($requestCount > 100) {
    // Limit exceeded: 100 requests per minute
    http_response_code(429);
    header('Content-Type: application/json');
    echo json_encode(['error' => 'Too many requests. Please slow down.']);
    exit;
}

I'll be honest: fixed windows have a flaw. If a user sends 100 requests at 10:00:59 and another 100 at 10:01:01, they've technically sent 200 requests in two seconds, even though they stayed within the "per minute" limit for both distinct windows. For most APIs, this is totally acceptable. If you're building something mission-critical or high-security, you'd look into a "Sliding Window" or "Token Bucket" algorithm, but those add significant complexity to your logic.

Communicating Limits to the Client

When you block a user, don't just send a generic 403 Forbidden. Use the 429 Too Many Requests HTTP status code. It's the industry standard and tells the client exactly what happened. To be a truly "good citizen" of the web, you should also include a Retry-After header, which tells the client exactly how many seconds to wait before trying again.

In a production environment, I usually wrap this logic into a Middleware class or a Guard component. This ensures that the rate limit check happens before any heavy business logic or database queries are executed. There is no point in calculating a complex search result if you're just going to throw it away because the user is over their limit.

📋 Practical Task

Exercise: Building a Redis-Backed API Guard for a Search Endpoint

You are tasked with protecting a hypothetical search endpoint /api/search.php from being abused by scrapers. You have a Redis server running locally.

Requirements:

• Implement a rate limiter that allows a maximum of 30 requests per minute per IP address.
• Use a Redis key pattern that includes the IP address and the current minute window to ensure the count resets every 60 seconds.
• If the user exceeds the limit, the script must:
  • Return a 429 Too Many Requests HTTP response code.
  • Set a Retry-After header indicating the number of seconds remaining until the next minute window begins.
  • Return a JSON object: {"error": "Rate limit exceeded", "retry_after": X}.
• If the user is within the limit, the script should simply print "Search results successfully retrieved."

Constraints: Use the PhpRedis extension or Predis library to interact with your Redis instance.