Implement Robust Rate Limiting Security

This skill designs and implements rate limiting to protect applications from abuse, DDoS attacks, brute-force attempts, and resource exhaustion, covering the security tradeoffs of different algorithms across architectures. It provides two core algorithms: Token Bucket (best for allowing burst traffic while holding a long-term rate limit) and Sliding Window Log (the most accurate but most memory-intensive option, best reserved for critical security endpoints), both with working implementations.

It covers a multi-layer defense-in-depth strategy with an Nginx configuration defining separate rate-limiting zones for global traffic, login endpoints, and API endpoints with burst allowances, plus an application-level Redis-backed distributed rate limiter using a sliding-window counter and a reusable rate-limiting decorator. Security-focused patterns include progressive penalties (escalating block durations - from a 1-minute throttle up to a 24-hour block - for repeat violators) and adaptive rate limiting that adjusts the effective limit based on a user's reputation score, a detected threat level, and current system load.

Security configuration guidance covers standard rate-limit response headers (limit, remaining, reset time, and retry-after) for client feedback, a composite identifier strategy that layers IP address, authenticated user ID, API key, and session ID for more precise limiting, and a metrics tracker that records allowed/blocked requests and violations by endpoint and identifier type for monitoring and alerting.

def add_rate_limit_headers(response, limit, remaining, reset_time):
    """Add standard rate limiting headers"""
    response.headers.update({
        'X-RateLimit-Limit': str(limit),
        'X-RateLimit-Remaining': str(remaining),
        'X-RateLimit-Reset': str(reset_time),
        'Retry-After': str(max(0, reset_time - int(time.time())))
    })
    return response

Use this skill when designing or hardening rate limiting for an application - choosing between token bucket and sliding window algorithms, layering Nginx and application-level limits, adding progressive penalties for repeat abusers, or building composite identifiers and monitoring for rate-limit decisions.

It is not a fit as a full DDoS-mitigation or WAF replacement - the implementation guidelines explicitly call for combining rate limiting with CAPTCHA and behavioral bot detection, and for whitelisting health checks and critical integrations rather than relying on rate limiting alone.

Inputs are the endpoints you need to protect, their expected legitimate traffic patterns, and which layers (network, application, database) need defense. Outputs are working Nginx zone configuration, a Redis-backed distributed rate limiter with a decorator for easy application, progressive-penalty and adaptive-limiting classes, standard rate-limit response headers, and a metrics tracker for monitoring and tuning.

Built on Nginx (limit_req_zone configuration) for edge-layer limiting and Redis (sorted sets via a pipeline) for distributed, application-level rate limiting.

Backend and security engineers implementing abuse protection who need concrete, production-ready rate-limiting patterns - algorithm selection, multi-layer defense, progressive penalties, and monitoring - following the 8-point implementation guidelines: layered defense, graceful degradation with extensive logging, whitelisting critical services, geographic and bot-detection integration, regular tuning against false positives, emergency bypass mechanisms, and full audit trails.