How to Add Referral and Loyalty Features to Your Booking System

Understanding Rate Limiting and Its Role in PHP Applications

When a single IP address makes hundreds of login attempts per minute against your PHP application, something has gone wrong. Without a mechanism to control request frequency, your application becomes vulnerable to automated attacks, resource exhaustion, and service degradation. Rate limiting provides that control by tracking how often a client can make requests within a defined period and taking action when limits are exceeded.

For PHP developers and website owners, implementing rate limiting is one of the most practical security measures you can add. It protects authentication systems from credential stuffing, shields API endpoints from abuse, and prevents a single user from monopolising server resources. This article walks through how rate limiting works, common implementation approaches in PHP, and what to consider before adding it to your application.

How Rate Limiting Works at the Application Level

The core concept behind rate limiting is straightforward. Your application maintains a record of requests from each client, usually identified by IP address, and compares that record against a defined threshold. If the client has exceeded the allowed number of requests within the time window, the application returns an error response instead of processing the request further.

Most rate limiting implementations use one of three response strategies when a limit is exceeded. Returning HTTP 429 (Too Many Requests) is the standard approach for APIs and provides clear feedback to well-behaved clients. A temporary connection block at the firewall level works for extreme cases but adds complexity. Serving a slower response or returning cached data can reduce server load while remaining technically accessible.

The storage mechanism for tracking request counts depends on your infrastructure. In-memory solutions like Redis offer fast read and write operations with automatic expiration of old records. Traditional databases work for lower-traffic applications but may introduce latency under heavy load. PHP sessions can track request counts for simpler applications but are limited to user-specific limiting rather than IP-based limiting.

Implementing Token Bucket Rate Limiting in PHP

The token bucket algorithm is a common approach to rate limiting that allows bursts of traffic while maintaining an average rate over time. Each client receives a bucket that fills with tokens at a fixed rate. Each request consumes a token, and requests are rejected when the bucket is empty.

Here is a practical implementation using Redis for storage:

<?php
class TokenBucketRateLimiter
{
    private Redis $redis;
    private string $key;
    private int $capacity;
    private float $refillRate;

    public function __construct(Redis $redis, string $identifier, int $capacity = 10, float $refillRate = 1.0)
    {
        $this->redis = $redis;
        $this->key = "ratelimit:{$identifier}";
        $this->capacity = $capacity;
        $this->refillRate = $refillRate;
    }

    public function attempt(): bool
    {
        $luaScript = <<<'LUA'
        local key = KEYS[1]
        local capacity = tonumber(ARGV[1])
        local refillRate = tonumber(ARGV[2])
        local now = tonumber(ARGV[3])

        local bucket = redis.call('HMGET', key, 'tokens', 'last_refill')
        local tokens = tonumber(bucket[1])
        local lastRefill = tonumber(bucket[2])

        if tokens == nil then
            tokens = capacity
            lastRefill = now
        end

        local elapsed = now - lastRefill
        local refillAmount = elapsed * refillRate
        tokens = math.min(capacity, tokens + refillAmount)

        if tokens >= 1 then
            tokens = tokens - 1
            redis.call('HMSET', key, 'tokens', tokens, 'last_refill', now)
            redis.call('EXPIRE', key, 3600)
            return 1
        else
            redis.call('HMSET', key, 'tokens', tokens, 'last_refill', now)
            redis.call('EXPIRE', key, 3600)
            return 0
        end
        LUA;

        return (bool) $this->redis->eval($luaScript, 1, $this->key, $this->capacity, $this->refillRate, microtime(true));
    }

    public function getRemainingTokens(): float
    {
        $bucket = $this->redis->hGetAll($this->key);
        if (empty($bucket)) {
            return $this->capacity;
        }

        $elapsed = microtime(true) - $bucket['last_refill'];
        $refillAmount = $elapsed * $this->refillRate;
        return max(0, min($this->capacity, $bucket['tokens'] + $refillAmount));
    }
}

Using Lua scripts with Redis ensures the check and update operations happen atomically, which prevents race conditions where multiple requests could slip through simultaneously.

A Simple Fixed Window Approach Without External Dependencies

For applications where adding Redis feels like overkill, a fixed window approach using a database or flat files can provide adequate protection. This method divides time into fixed intervals and resets the counter at the start of each window.

<?php
class FixedWindowRateLimiter
{
    private PDO $pdo;
    private string $ip;
    private int $maxRequests;
    private int $windowSeconds;

    public function __construct(PDO $pdo, string $ip, int $maxRequests = 60, int $windowSeconds = 60)
    {
        $this->pdo = $pdo;
        $this->ip = $ip;
        $this->maxRequests = $maxRequests;
        $this->windowSeconds = $windowSeconds;
    }

    public function isAllowed(): bool
    {
        $windowStart = floor(time() / $this->windowSeconds) * $this->windowSeconds;

        $stmt = $this->pdo->prepare(
            'SELECT request_count FROM rate_limits 
             WHERE ip_address = ? AND window_start = ?'
        );
        $stmt->execute([$this->ip, $windowStart]);
        $row = $stmt->fetch(PDO::FETCH_ASSOC);

        if ($row && $row['request_count'] >= $this->maxRequests) {
            return false;
        }

        $stmt = $this->pdo->prepare(
            'INSERT INTO rate_limits (ip_address, window_start, request_count, last_request)
             VALUES (?, ?, 1, NOW())
             ON DUPLICATE KEY UPDATE 
                request_count = request_count + 1,
                last_request = NOW()'
        );
        $stmt->execute([$this->ip, $windowStart]);

        return true;
    }
}

The database table for this approach needs an index on the combination of ip_address and window_start for efficient lookups. Here is the basic schema:

CREATE TABLE rate_limits (
    id INT AUTO_INCREMENT PRIMARY KEY,
    ip_address VARCHAR(45) NOT NULL,
    window_start INT UNSIGNED NOT NULL,
    request_count INT UNSIGNED DEFAULT 1,
    last_request DATETIME DEFAULT CURRENT_TIMESTAMP,
    UNIQUE KEY idx_ip_window (ip_address, window_start),
    KEY idx_window_start (window_start)
);

Protecting Login Endpoints with Rate Limiting

Authentication pages are prime targets for brute force attacks. An attacker cycling through common password combinations can test thousands of credentials per hour without rate limiting in place. Adding rate limiting to your login endpoint significantly raises the difficulty of such attacks.

For login pages, consider using stricter limits than your general endpoints. A typical configuration might allow five login attempts per IP address over a fifteen-minute window. After exceeding this limit, temporarily block further attempts from that IP for a cooling-off period.

<?php
function checkLoginRateLimit(PDO $pdo, string $ip): array
{
    $windowStart = time() - 900;
    $stmt = $pdo->prepare(
        'SELECT COUNT(*) FROM login_attempts 
         WHERE ip_address = ? AND attempted_at > ? AND blocked = 0'
    );
    $stmt->execute([$ip, $windowStart]);
    $attempts = (int) $stmt->fetchColumn();

    if ($attempts >= 5) {
        $stmt = $pdo->prepare(
            'SELECT MAX(attempted_at) FROM login_attempts 
             WHERE ip_address = ? AND blocked = 1'
        );
        $stmt->execute([$ip]);
        $lastBlocked = $stmt->fetchColumn();

        if ($lastBlocked && (time() - $lastBlocked) < 1800) {
            $retryAfter = 1800 - (time() - $lastBlocked);
            http_response_code(429);
            header("Retry-After: {$retryAfter}");
            exit('Too many login attempts. Please try again later.');
        }

        $stmt = $pdo->prepare(
            'INSERT INTO login_attempts (ip_address, attempted_at, blocked) VALUES (?, ?, 1)'
        );
        $stmt->execute([$ip, time()]);
        http_response_code(429);
        exit('Too many login attempts. Please try again in 30 minutes.');
    }

    return ['attempts' => $attempts, 'remaining' => 5 - $attempts];
}

When rate limiting triggers on a login endpoint, log the event including the IP address, timestamp, and user agent. This information helps identify patterns in attack attempts and can inform broader security decisions.

Rate Limiting APIs Built with PHP

REST APIs face different challenges than web pages. API consumers expect consistent behaviour and clear feedback about rate limit status. Standard practice involves including rate limit headers in responses so clients can adjust their request behaviour accordingly.

<?php
class ApiRateLimiter
{
    private Redis $redis;
    private string $apiKey;
    private int $requestsPerMinute;

    public function __construct(Redis $redis, string $apiKey, int $requestsPerMinute = 60)
    {
        $this->redis = $redis;
        $this->apiKey = $apiKey;
        $this->requestsPerMinute = $requestsPerMinute;
    }

    public function check(): array
    {
        $key = "api_ratelimit:{$this->apiKey}";
        $window = 60;

        $current = (int) $this->redis->get($key);

        if ($current >= $this->requestsPerMinute) {
            $ttl = $this->redis->ttl($key);
            $this->sendRateLimitHeaders($this->requestsPerMinute, 0, $ttl);
            http_response_code(429);
            header('Content-Type: application/json');
            echo json_encode([
                'error' => 'Rate limit exceeded',
                'retry_after' => $ttl
            ]);
            exit;
        }

        $this->redis->incr($key);
        if ($current === 0) {
            $this->redis->expire($key, $window);
        }

        $remaining = $this->requestsPerMinute - $current - 1;
        $ttl = $this->redis->ttl($key);

        $this->sendRateLimitHeaders($this->requestsPerMinute, $remaining, $ttl);

        return ['allowed' => true, 'remaining' => $remaining];
    }

    private function sendRateLimitHeaders(int $limit, int $remaining, int $resetIn): void
    {
        header("X-RateLimit-Limit: {$limit}");
        header("X-RateLimit-Remaining: {$remaining}");
        header("X-RateLimit-Reset: " . (time() + $resetIn));
    }
}

API clients that follow best practices will check these headers and throttle their own requests accordingly. This creates a cooperative environment where well-behaved clients can maximise their throughput without affecting service quality for others.

When Sliding Window Rate Limiting Makes More Sense

The fixed window approach has a notable weakness. If a user exhausts their limit at the end of one window, they can immediately exhaust it again at the start of the next. This effectively doubles the available requests per user in any given minute. Sliding window rate limiting addresses this by calculating limits based on a continuous time period rather than fixed buckets.

For high-traffic applications where precision matters, the sliding window algorithm using Redis sorted sets provides accurate rate limiting:

<?php
class SlidingWindowRateLimiter
{
    private Redis $redis;
    private string $identifier;
    private int $maxRequests;
    private int $windowSeconds;

    public function __construct(Redis $redis, string $identifier, int $maxRequests = 100, int $windowSeconds = 60)
    {
        $this->redis = $redis;
        $this->identifier = $identifier;
        $this->maxRequests = $maxRequests;
        $this->windowSeconds = $windowSeconds;
    }

    public function isAllowed(): bool
    {
        $key = "sliding_ratelimit:{$this->identifier}";
        $now = microtime(true);
        $windowStart = $now - $this->windowSeconds;

        $this->redis->zRemRangeByScore($key, '-inf', $windowStart);

        $currentCount = $this->redis->zCard($key);

        if ($currentCount >= $this->maxRequests) {
            return false;
        }

        $this->redis->zAdd($key, $now, $now . ':' . uniqid());
        $this->redis->expire($key, $this->windowSeconds + 1);

        return true;
    }

    public function getRetryAfter(): int
    {
        $key = "sliding_ratelimit:{$this->identifier}";
        $windowStart = microtime(true) - $this->windowSeconds;

        $oldestEntries = $this->redis->zRange($key, 0, 0, ['WITHSCORES' => true]);

        if (empty($oldestEntries)) {
            return 0;
        }

        $oldestTimestamp = reset($oldestEntries);
        return (int) ceil(($oldestTimestamp + $this->windowSeconds) - microtime(true));
    }
}

This approach stores each request timestamp in a sorted set, allowing precise calculation of how many requests fall within the current sliding window. The trade-off is slightly higher memory usage compared to fixed window approaches.

Common Mistakes When Implementing Rate Limiting

Several implementation errors reduce the effectiveness of rate limiting or create problems for legitimate users. Identifying these mistakes helps you avoid them in your own implementation.

Using IP address alone for identification. Many users appear to share a single IP address when behind corporate NAT gateways or VPN exit points. Rate limiting by IP alone can block legitimate users who happen to share an exit point. Consider combining IP address with other signals like API keys, user accounts, or browser fingerprints for more granular limiting.

Failing to handle distributed environments. If your application runs across multiple servers, storing rate limit state in local memory or single-server databases creates inconsistencies. Attackers can simply distribute their requests across your server pool. Use shared storage like Redis or a centralised database that all application instances can access.

Setting limits too aggressively. Conservative rate limits protect against abuse but can frustrate legitimate users. A user legitimately browsing through product pages should not trigger rate limiting on an API. Calibrate your limits based on actual usage patterns rather than theoretical maximums.

Not providing useful feedback. Generic error pages when rate limits trigger confuse users and provide no actionable information. Include clear messaging about when the limit will reset and what the policy is. If building an API, use standard headers so clients can programmatically handle rate limiting.

Performance Considerations for PHP Rate Limiting

Rate limiting logic adds overhead to every request, so implementation efficiency matters. The storage backend you choose significantly impacts this overhead. In-memory solutions like Redis typically respond in under a millisecond. Database queries may take several milliseconds, and this latency multiplies across thousands of requests per second.

For most PHP applications, rate limiting middleware should execute early in the request lifecycle, before any expensive operations like database queries or API calls. This ensures you reject abusive requests as cheaply as possible rather than performing work only to reject it.

Consider caching your rate limit configuration rather than reading it from a database on every request. If you support different rate limits for different endpoints or user tiers, store this configuration in a fast cache layer and refresh it periodically rather than on every single request.

Monitoring and Logging Rate Limit Events

Rate limiting only provides value if you can observe how it performs in production. Log rate limit violations with enough context to identify patterns and assess whether your limits are calibrated appropriately.

<?php
function logRateLimitEvent(PDO $pdo, string $ip, string $endpoint, string $limitType, int $currentCount): void
{
    $stmt = $pdo->prepare(
        'INSERT INTO rate_limit_logs (ip_address, endpoint, limit_type, request_count, logged_at)
         VALUES (?, ?, ?, ?, NOW())'
    );
    $stmt->execute([$ip, $endpoint, $limitType, $currentCount]);

    if (isSkippedIp($ip)) {
        return;
    }

    error_log(sprintf(
        '[RATE_LIMIT] IP: %s | Endpoint: %s | Type: %s | Count: %d',
        $ip,
        $endpoint,
        $limitType,
        $currentCount
    ));
}

Review these logs periodically to identify IPs that repeatedly trigger limits, which may indicate coordinated attacks. Also watch for sudden spikes in rate limit violations that could signal a new attack vector or misconfiguration.

Integrating Rate Limiting with Application Logic

For booking systems and business applications, rate limiting serves purposes beyond security. If your booking platform processes reservation requests, rate limiting prevents a single customer from repeatedly hammering your availability check endpoint and creating artificial load. This is particularly relevant for custom booking systems where the complexity of availability calculations can make each request computationally expensive.

Understanding the relationship between your application architecture and rate limiting requirements helps you position limiting logic effectively. In some cases, placing rate limits at the web server level using Nginx or Apache directives provides better performance than application-level limiting, since requests never reach PHP at all when limits are exceeded.

Nginx provides a mature rate limiting module that works well for many PHP applications:

http {
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
    limit_req_zone $binary_remote_addr zone=api:10m rate=60r/m;

    server {
        location = /login {
            limit_req zone=login burst=5 nodelay;
            limit_req_status 429;
            include fastcgi_params;
            fastcgi_pass unix:/var/run/php/php-fpm.sock;
        }

        location /api {
            limit_req zone=api burst=20 nodelay;
            limit_req_status 429;
            include fastcgi_params;
            fastcgi_pass unix:/var/run/php/php-fpm.sock;
        }
    }
}

Combining web server-level limiting with application-level logic provides defence in depth. The web server handles extreme cases efficiently, while application-level logic can implement more sophisticated policies based on user authentication state, account tier, or endpoint-specific requirements.

Testing Your Rate Limiting Implementation

Thorough testing ensures your rate limiting behaves correctly under various conditions. Write tests that verify the limiting logic itself, not just that it returns error codes when triggered.

Test scenarios should include normal usage patterns that should never trigger limits, burst scenarios that test whether limits activate at the correct threshold, and recovery scenarios that confirm limits reset properly after the window expires. Also test edge cases like clock drift, concurrent requests from the same IP, and behaviour when the storage backend becomes unavailable.

For integration testing, tools like Apache JMeter or Locust can simulate multiple concurrent users and verify that aggregate behaviour matches your rate limiting configuration. Load testing with realistic traffic patterns helps identify whether your storage backend can handle the request volume without becoming a bottleneck.

Related practical reading

These related guides can help you connect this topic with the wider website, server, security, and support decisions around it.

• GraphQL in PHP vs REST: When GraphQL Is the Better Choice - useful background for related development decisions
• PHP 8.4: Property Hooks and Asymmetric Visibility - useful background for related development decisions

Putting Rate Limiting into Practice

Rate limiting is one of those security measures where the implementation complexity is low but the protective value is significant. A properly configured rate limiter takes hours to implement but can prevent the kind of automated attacks that compromise user accounts or exhaust server resources.

Start with your most vulnerable endpoints and expand from there. Login pages and authentication endpoints should be your first priority. Add rate limiting to sensitive API endpoints as your application evolves. The token bucket and fixed window approaches covered here work well for most PHP applications, and more sophisticated implementations like sliding window limiting are available when you need greater precision.

If you are running an existing PHP application and want to add rate limiting protection, audit your current endpoints to identify which ones lack this protection. Even a basic implementation can meaningfully reduce your exposure to automated attacks.

For applications where performance and scalability matter, consider how rate limiting integrates with your broader infrastructure including caching layers, load balancers, and CDN configuration. The examples in this article use Redis and PDO as storage backends, but the underlying principles apply regardless of your specific technology choices.