Rate Limiting — False 429 Errors from Partial Node Updates

Every production system you'll ever work on will eventually face the same villain: a surge of traffic that nobody planned for. It might be a viral moment, a misconfigured client hammering your API in a loop, or a bad actor trying to scrape your data. Without a gate, that surge hits your database, your CPU, and your users — all at once. Rate limiting is that gate, and understanding its internals is the difference between an API that survives launch day and one that doesn't.

The core problem rate limiting solves is resource fairness under pressure. Your server has finite CPU, memory, and I/O bandwidth. If one client can fire 10,000 requests per second, every other client suffers. Rate limiting enforces a contract: you get X requests in Y time, and anything beyond that gets slowed down or rejected. It protects downstream services, enforces pricing tiers (free vs. paid plans), and prevents abuse — all without you needing to scale hardware every time someone writes a bad for-loop.

I've implemented rate limiters at three different scale levels — from a 200 RPS internal tool to a public API handling 80k+ RPS during peak hours. By the end of this article you'll know the four main rate limiting components and how they fit together, understand the trade-offs between Token Bucket, Leaky Bucket, Fixed Window, and Sliding Window algorithms, be able to sketch a distributed rate limiter on a whiteboard, and recognise the two mistakes that still burn engineers in production. Let's build it piece by piece.

Why Rate Limiting Is Not Optional

Rate limiting is a mechanism that controls how many requests a client can make to a service within a given time window. At its core, it's a traffic cop: if a client exceeds the defined threshold, subsequent requests are rejected with HTTP 429 (Too Many Requests). The two primary algorithms are token bucket (burst-tolerant, O(1) per check) and sliding window (smoother, O(log n) with sorted sets).

In practice, rate limits are enforced at the edge (API gateway) or in the application layer. The key property that matters: rate limiting is distributed. Each node in a cluster maintains its own counter, and without a shared state (Redis, etc.), a client can be throttled on one node while another node still accepts requests. This asymmetry is the root cause of false 429 errors during partial node updates.

You use rate limiting to protect backend resources from abuse, ensure fair usage among tenants, and maintain system stability under load. Without it, a single aggressive client can degrade latency for everyone, trigger cascading failures, or exhaust connection pools. In multi-tenant SaaS, it's the difference between a noisy neighbor and a platform outage.

The Four Core Components Every Rate Limiter Needs

A rate limiter isn't a single thing — it's a pipeline of four cooperating components. Knowing each one's job tells you exactly where to look when something goes wrong in production.

1. The Rule Store holds the policy: who gets how many requests, over what time window, and for which endpoint. Rules might say 'free-tier users get 100 requests/minute on /search, paid users get 1000.' In my last company we kept this in a DynamoDB table with hot-reload support — changing a tier’s limit took effect in under 3 seconds without restarting any service.

2. The Counter/State Store is where the actual counting happens. For single-node systems this can be in-memory. For distributed systems it's almost always Redis — because Redis is fast, atomic, and shared across every server in your cluster. This is the most critical component: if it's wrong, your limits are wrong. I once saw a team lose an entire weekend because their Redis cluster was partitioned and two nodes were counting independently.

3. The Decision Engine is the algorithm. It reads the state from the counter store, applies the rule from the rule store, and returns one of three verdicts: ALLOW, THROTTLE (slow down), or REJECT. The algorithm you pick here defines the user experience — smooth and forgiving vs. hard cutoffs.

4. The Response Handler communicates the decision back to the caller. A well-behaved rate limiter doesn't just drop requests silently — it returns HTTP 429 with headers like Retry-After, X-RateLimit-Limit, and X-RateLimit-Remaining so clients can back off gracefully. In one production incident, adding these headers reduced our retry storm by 68% overnight.

# io.thecodeforge.ratelimiting.components

import time
import threading
from dataclasses import dataclass, field
from typing import Dict, Tuple

# ─── COMPONENT 1: Rule Store ───────────────────────────────────────────────
# In production this would be loaded from a config file or database.
RATE_LIMIT_RULES: Dict[str, Tuple[int, int]] = {
    # tier_name: (max_requests, window_seconds)
    "free":       (10, 60),    # 10 requests per minute
    "paid":       (100, 60),   # 100 requests per minute
    "enterprise": (1000, 60),  # 1000 requests per minute
}

# ─── COMPONENT 2: Counter Store (in-memory, thread-safe) ───────────────────
# In a distributed system, replace this with a Redis INCR + EXPIRE call.
@dataclass
class WindowCounter:
    count: int = 0
    window_start: float = field(default_factory=time.time)

class InMemoryCounterStore:
    def __init__(self):
        self._store: Dict[str, WindowCounter] = {}
        self._lock = threading.Lock()  # Prevents race conditions in multi-threaded apps

    def increment_and_get(self

The Four Algorithms: Token Bucket vs Sliding Window vs the Rest

The Decision Engine can use several different algorithms, and the one you pick has a profound effect on user experience and system complexity. Here's how each one thinks.

Fixed Window (what we coded above) splits time into hard buckets — e.g. every minute resets to zero. It's simple, but has a nasty edge case: a client can fire 10 requests at 12:00:59 and another 10 at 12:01:01, effectively getting 20 requests in 2 seconds. This is called the boundary burst problem.

Sliding Window Log fixes this by storing a timestamp for every request and counting only those within the last N seconds. Accurate, but expensive in memory — you're storing one record per request.

Sliding Window Counter is the pragmatic middle ground: it blends the previous window's count with the current one using a weighted average. Much lighter on memory, still smooth.

Token Bucket is what most major APIs (Stripe, GitHub, AWS) actually use. Think of it as a bucket that refills at a steady rate — say, 2 tokens per second up to a max of 10. Each request costs one token. This naturally allows short bursts (drain the bucket) while enforcing a long-term average rate (the refill rate). It's the most user-friendly algorithm because it doesn't punish bursty-but-reasonable traffic.

Leaky Bucket is Token Bucket's stricter cousin. Requests go into a queue (the bucket) and are processed at a fixed rate. Excess requests overflow and are dropped. Use it when you need perfectly smooth output, like protecting a downstream service that can't handle any spikes.

# io.thecodeforge.ratelimiting.token_bucket

import time
import threading
from dataclasses import dataclass

# Token Bucket Algorithm
# WHY use this? It allows short bursts of traffic while enforcing a
# long-term average rate. Stripe, GitHub, and Twilio all use variants of this.

@dataclass
class TokenBucket:
    capacity: int          # Maximum tokens the bucket can hold (burst limit)
    refill_rate: float     # Tokens added per second (steady-state limit)
    _tokens: float = 0.0
    _last_refill_time: float = 0.0
    _lock: threading.Lock = None

    def __post_init__(self):
        self._tokens = float(self.capacity)  # Start full — first burst is always allowed
        self._last_refill_time = time.monotonic()  # monotonic is safer than time.time() for intervals
        self._lock = threading.Lock()

    def _refill(self):
        """Called before every consume() to add tokens earned since last request."""
        now = time.monotonic()
        elapsed_seconds = now - self._last_refill_time

        # How many tokens have we earned in the time since the last request?
        tokens_earned = elapsed_seconds * self.refill_rate

        # Cap at capacity — you can't save up more than the bucket holds
        self._tokens = min(self.capacity, self._tokens + tokens_earned)
        self._last_refill_time = now

    def consume(self, tokens_needed: int = 1) -> bool:
        """Try to consume tokens. Returns True if allowed, False if rate-limited."""
        with self._lock:  # Thread-safe — critical in async/multi-threaded servers
            self._refill()

            if self._tokens >= tokens_needed:
                self._tokens -= tokens_needed
                return True  # ALLOW
            return False     # REJECT — not enough tokens

    @property
    def tokens_available(self) -> float:
        """Read current token count (approximate — for logging only)."""
        with self._lock:
            self._refill()
            return round(self._tokens, 2)


def simulate_api_traffic():
    """
    Simulates a realistic traffic pattern:
    - An initial burst (legitimate, e.g. app startup)
    - Steady traffic
    - Another burst that partially hits the limit
    """
    # 5 tokens max (burst), refills at 1 token/second (steady-state: 1 req/sec)
    bucket = TokenBucket(capacity=5, refill_rate=1.0)

    print("=== Simulating Token Bucket Rate Limiter ===")
    print(f"Config: capacity=5 tokens, refill=1 token/second\n")

    # Phase 1: Burst of 7 requests (only 5 should pass — bucket starts full at 5)
    print("[Phase 1] Burst of 7 requests fired instantly:")
    for req_num in range(1, 8):
        allowed = bucket.consume()
        status = "ALLOW ✓" if allowed else "REJECT ✗"
        print(f"  Request #{req_num}: {status} | Tokens left: {bucket.tokens_available}")

    # Phase 2: Wait 3 seconds — bucket refills 3 tokens
    print("\n[Phase 2] Waiting 3 seconds for bucket to refill...")
    time.sleep(3)
    print(f"  Tokens after 3s wait: {bucket.tokens_available}")

    # Phase 3: Send 4 more requests — 3 should pass, 1 should be rejected
    print("\n[Phase 3] Sending 4 more requests after refill:")
    for req_num in range(8, 12):
        allowed = bucket.consume()
        status = "ALLOW ✓" if allowed else "REJECT ✗"
        print(f"  Request #{req_num}: {status} | Tokens left: {bucket.tokens_available}")


if __name__ == "__main__":
    simulate_api_traffic()

All Five Algorithms Compared: Pros, Cons, and Best Fit

Choosing the right algorithm depends on your traffic patterns, accuracy needs, and operational cost. Here's a breakdown of each algorithm with explicit pros and cons.

### Fixed Window - Pros: Extremely simple to implement, low memory (one counter per client per window), no need for timestamps beyond window start. - Cons: Suffers from the boundary burst problem — clients can double their rate at window edges. Not suitable for any use case requiring smooth or fair distribution. - Best fit: Internal tools, low-stakes APIs where occasional bursts are acceptable.

### Sliding Window Log - Pros: Perfectly accurate — counts exactly how many requests occurred in the last N seconds. No boundary burst. Ideal for audit-trail requirements. - Cons: Memory-inefficient — stores a timestamp per request. For high-traffic clients, this can become expensive. O(n) memory per client. - Best fit: Security rate limiting, financial systems, or any scenario where you need an exact log.

### Sliding Window Counter - Pros: Excellent trade-off between accuracy and memory. Uses two counters (current and previous window) and a weighted average. Approximation error is small (typically <1%). - Cons: Slightly more complex than Fixed Window. Not perfectly exact. - Best fit: Most production APIs — delivers smooth limiting without the memory cost of sliding window log.

### Token Bucket - Pros: Allows natural bursts up to capacity, then enforces a steady-state average via refill rate. Intuitive parameters map to product limits. Widely used by major APIs (Stripe, GitHub, AWS). - Cons: Refill rate and capacity must be carefully tuned — too aggressive starves legitimate bursts, too lenient defeats the limit. Not exact — a burst can temporarily exceed the average. - Best fit: User-facing APIs, SDKs, any traffic pattern with natural bursts (app startup, pagination).

### Leaky Bucket - Pros: Produces perfectly smooth output — requests are processed at a fixed rate. Protects fragile downstream services from any spike. - Cons: No burst capability — all requests are queued, which can add latency. If the queue fills, requests are dropped without buffering. - Best fit: Protecting databases, payment gateways, or any downstream service that cannot tolerate sudden load increases.

Visualizing Token Bucket and Leaky Bucket

Understanding how these two algorithms work is easier with a visual. The diagram below shows the core flow of Token Bucket (allowing bursts up to capacity) and Leaky Bucket (smoothing output to a fixed rate).

Algorithm Selection Guide: When to Use Each Rate Limiting Algorithm

Choosing among the five algorithms comes down to three questions: Do you need exact counts? Does your traffic come in bursts? Is your downstream service fragile?

Use Fixed Window when: - You need a quick, low-overhead limiter for internal tools or non-critical paths. - You can tolerate occasional double-bursts at window boundaries. - Memory is tight and you have many clients.

Use Sliding Window Log when: - Every single request must be audited with perfect accuracy (e.g., billing, security). - You have the memory budget to store a timestamp per request. - Boundary bursts are unacceptable.

Use Sliding Window Counter when: - You want the best accuracy-to-cost ratio. - You can accept a tiny approximation error (~1%). - You are building the default rate limiter for most API endpoints.

Use Token Bucket when: - You are building a user-facing API where bursts are natural (app startup, refresh, pagination). - You want simple parameters that map to product limits (e.g., "burst up to 10 requests, then 1 per second"). - You follow the pattern of Stripe, GitHub, and AWS.

Use Leaky Bucket when: - You need to protect a fragile downstream service that cannot tolerate any spikes (e.g., a legacy database, a payment gateway). - Perfectly smooth output is more important than allowing bursts. - You accept that a full queue causes immediate request drops.

Distributed Rate Limiting: Why Redis Is the State Store of Choice

Everything above works perfectly on a single server. The moment you have two servers behind a load balancer, you have a problem: each server has its own in-memory counter. If user_42 hits server A for 8 requests and server B for 8 requests, both servers think the limit hasn't been hit — but the user actually sent 16 requests. Your rate limiter is broken.

The fix is a shared, atomic state store — and Redis is the industry-standard answer. Redis is single-threaded internally, which means its commands are inherently atomic. The INCR command increments a key and returns the new value in a single atomic operation. Pair that with EXPIRE to auto-delete the key when the window ends, and you have a thread-safe, distributed-safe counter with two lines of Redis.

For the sliding window counter in Redis, the pattern is slightly more sophisticated: use a sorted set (ZADD) where each member is a request timestamp, then use ZCOUNT to count members in the last N seconds and ZREMRANGEBYSCORE to evict old entries. This gives you perfect accuracy without the boundary burst problem of fixed windows.

The critical trade-off: Redis adds a network round-trip (typically 0.1–2ms) to every single request decision. For most APIs that's fine. For ultra-low-latency scenarios (sub-5ms response time targets), consider a two-layer approach: a local in-memory limiter for coarse-grained fast rejection, with Redis as the authoritative source for precise enforcement.

# io.thecodeforge.ratelimiting.distributed
# Requires: pip install redis
# Assumes Redis running on localhost:6379
# Run: docker run -p 6379:6379 redis

import redis
import time
from typing import Tuple

# ─── Redis connection ────────────────────────────────────────────────────────
# In production, use connection pooling and a Redis Sentinel or Cluster setup
redis_client = redis.Redis(
    host="localhost",
    port=6379,
    db=0,
    decode_responses=True  # Return strings, not bytes
)

class DistributedFixedWindowLimiter:
    """
    Uses Redis INCR + EXPIRE for atomic, distributed-safe counting.
    WHY INCR? It's a single atomic command — no race condition between
    'read current count' and 'write new count' that you'd get in application code.
    """

    def __init__(self

When Your Rate Limiter Breaks: Debugging Common Production Failures

Rate limiters fail in subtle ways. The most common? Silent degradation where the limiter lets too many requests through because Redis was partitioned and each node counted independently. Another classic: a client gets 429s despite being within limits because the clock on the rate limiter server is skewed a few minutes ahead — the window appears full when it shouldn't be.

False positives happen when the state store is too coarse (e.g., IP-based limits inside a corporate NAT). You'll see a flood of support tickets from one company whose employees can't access your API. False negatives happen when Redis goes down and the fallback allow logic stays silent — your service gets hammered.

Debugging these requires visibility. Log every rate limit decision (ALLOW, REJECT, reason) with client ID, endpoint, and time. Use structured logs. If you can't see which decision your limiter made, you're flying blind.

Another trap: burst smoothing. A naive Token Bucket might allow a 5x burst in one second, which downstream databases hate. Always add a secondary per-second limiter before the database layer.

Where to Place Rate Limiters: API Gateway, Application Layer, or Load Balancer?

Rate limiters can live at different layers of your infrastructure. Each placement has trade-offs in terms of flexibility, latency, and management overhead.

### API Gateway (e.g., Kong, AWS API Gateway, Apigee) - Pros: Centralized configuration — change limits without touching application code. Often includes built-in support for token bucket or fixed window. Easiest to maintain across many services. - Cons: Limited algorithm choices — most gateways only offer fixed window or basic token bucket. Can become a bottleneck if not scaled. Adds unavoidable latency (typically 1-5ms). - Best for: Teams with multiple microservices that need uniform rate limit policies. Also good for external-facing APIs where a separate gateway already exists.

### Application Layer (within your service code) - Pros: Full control — you can use any algorithm, tie limits to business logic (e.g., different limits per user role), and implement per-endpoint cost-based limits. Lowest latency (in-memory counters). - Cons: Requires implementing and maintaining the rate limiter in each service. Harder to enforce cross-service limits (e.g., total requests across all endpoints). Code duplication risk. - Best for: Services with custom or complex rate limit needs. Also for latency-sensitive endpoints where an extra network hop is unacceptable.

### Load Balancer (e.g., Nginx, HAProxy, AWS ALB) - Pros: Very low overhead — load balancers are optimized for fast packet processing. Can rate-limit before requests even reach your application, providing a hard outer defense. Some support connection limiting and request rate limiting. - Cons: Limited to simple algorithms (mostly fixed window or connection-based). Cannot inspect request bodies or custom headers deeply. Difficult to implement per-user or per-tier limits (load balancers typically operate at IP level). - Best for: First line of defense against DDoS or brute-force attacks. Use for coarse-grained IP-based limits before applying finer-grained limits in the application.

### Recommendation: Layered Approach Start with a load balancer for IP-based rate limiting (protect against DDoS). Add an API Gateway for tenant-based limits if you have multiple services. Then implement application-layer rate limiting with Token Bucket for user-specific logic. This gives you defense in depth.

Client-Side vs Server-Side Rate Limiting: Pick Your Poison

Most engineers treat rate limiting as a server problem. They slap middleware on the API gateway and declare victory. That's half the story—and honestly, the easy half.

Client-side rate limiting puts the brakes on the caller's machine. The client tracks its own usage and backs off before it hits the server's limits. Sounds polite, right? Problem is, you're trusting the attacker to play nice. No one brute-forces your login endpoint and then says "oops, my local counter says I'm done." Client-side is for cooperative traffic—internal microservices, SDKs you control, webhook retries. Never for untrusted clients.

Server-side is where you enforce reality. The server owns the window, tracks every request, and returns 429 responses when some API abuser exceeds their quota. It's the only way to stop abuse. But it's not free: every request burns a Redis call, a cache lookup, or a synchronous counter update. That latency adds up under load.

The pro move? Both. Use client-side as a polite hint to reduce chatter, and server-side as the hard stop. The client avoids useless round-trips; the server keeps the system alive.

// io.thecodeforge — system-design tutorial

import time
import requests

class ClientSideThrottle:
    """Honor-system token bucket."""
    def __init__(self, tokens, window_sec):
        self.tokens = tokens
        self.window_sec = window_sec
        self.last_check = time.time()
        self.available = tokens

    def allow(self):
        now = time.time()
        elapsed = now - self.last_check
        self.available = min(self.tokens,
                            self.available + elapsed * (self.tokens / self.window_sec))
        self.last_check = now
        if self.available >= 1:
            self.available -= 1
            return True
        return False

client_throttle = ClientSideThrottle(5, 60)
for _ in range(7):
    if client_throttle.allow():
        requests.get("https://api.store.com/products?sku=ARC-101")
        print("Request sent")
    else:
        print("Blocked by client — no point calling server")

Types of Rate Limiting: IP-Based vs Server-Based vs Geography-Based

A rate limiter that treats all traffic the same is a blunt instrument. You need to decide what you're actually limiting. The type defines the granularity of control—and gets you out of firefighting mode.

IP-based rate limiting keys on the client's source IP. Simple to implement, no auth required. But it falls apart under NAT—hundreds of real users behind one office IP all get throttled because one idiot wrote a scraping script. Also, attackers rotate IPs faster than you can update your rules. Use it as a first line of defense, not your only one.

Server-based rate limiting ties quotas to authenticated users or API keys. This is the gold standard. You know who's calling you. You can give different tiers (free users get 1000/hr, premium get 100k/hr). The tricky part: you need auth before you can check the limit. That adds a hop. And in a microservice mesh, you need a shared state layer (Redis) to keep counts consistent across instances.

Geography-based limiting blocks or throttles by region. Use it when you see a traffic surge from a country where you have zero customers. Or when a DDoS originates from a specific ASN. It's coarse, but fast. Just be careful—you might block a CDN edge node serving legit users. Whitelist your partners.

The senior move: combine them. IP-based as a quick filter, then user-based for fine-grained controls, then geo-based for emergency circuit-breaking.

// io.thecodeforge — system-design tutorial

import redis
import time

r = redis.Redis(host="redis-gateway.prod", port=6379, decode_responses=True)

def check_ip_limit(ip: str, max_reqs: int, window: int) -> bool:
    key = f"rate_limit:ip:{ip}"
    current = r.incr(key)
    if current == 1:
        r.expire(key, window)
    return current <= max_reqs

def check_user_limit(user_id: str, max_reqs: int, window: int) -> bool:
    key = f"rate_limit:user:{user_id}"
    current = r.incr(key)
    if current == 1:
        r.expire(key, window)
    return current <= max_reqs

def check_geo_limit(country: str, allowed: list) -> bool:
    return country in allowed

# Production usage
ip_ok = check_ip_limit("203.0.113.42", 100, 60)
if not ip_ok:
    print("Blocked: IP exceeded limit")
else:
    user_ok = check_user_limit("user_abc_789", 1000, 3600)
    geo_ok = check_geo_limit("RU", ["US", "CA", "GB"])
    if user_ok and geo_ok:
        print("Request allowed")
    else:
        print("Blocked: user or geo limit hit")

Use Cases: Where Rate Limiting Saves Your Bacon (or Doesn't)

Rate limiting isn't a theory exercise — it's the difference between your API surviving Black Friday and sending 503s to every paying customer. The most obvious use case is protecting backend resources from abuse: a single rogue client hammering your database with 10k requests per second will take down the whole cluster. Rate limiting stops that at the door.

But the real money is in tiered access control. Your free-tier API users don't get the same throughput as your enterprise clients paying $50k/month. Rate limiting enforces those business rules without custom logic per customer. Same for pricing fairness — one tenant in a shared system shouldn't starve others because they wrote a bad loop.

Where it often fails is when engineers treat it as a universal shield. Rate limiting won't protect against DDoS at the network layer — that's a firewall job. It won't fix poorly optimized endpoints that are slow by design. And if your rate limiter itself becomes the bottleneck (e.g., Redis cluster goes down), you've traded one failure mode for a worse one. Know where you're applying it and why.

// io.thecodeforge — system-design tutorial

class TieredRateLimiter:
    def __init__(self, redis_client):
        self.redis = redis_client
        self.tiers = {"free": 10, "pro": 100, "enterprise": 10000}

    def check_and_throttle(self, api_key, user_tier):
        limit = self.tiers.get(user_tier, 10)
        current = self.redis.get(f"rate:{api_key}")
        if current and int(current) >= limit:
            return False  # 429 Too Many Requests
        self.redis.incr(f"rate:{api_key}")
        self.redis.expire(f"rate:{api_key}", 60)
        return True

limiter = TieredRateLimiter(redis)
print(limiter.check_and_throttle("key_free_1", "free"))  # True
print(limiter.check_and_throttle("key_free_1", "free"))  # True (up to 10)

Challenges: The Five Ways Your Rate Limiter Will Betray You

First: consistency vs. availability is a real choice. In distributed systems, enforcing a global rate limit requires consensus. If your Redis leader goes down and you fall back to local counters, you'll overcount by 5-10%. Is that acceptable? Depends on whether you're protecting a payment gateway or a read-only cache.

Second: clock skew kills sliding windows. If your servers disagree on time by even 200ms, your window logic breaks. You'll throttle users who shouldn't be throttled and let abusers through. Use monotonic clocks (time.monotonic in Python) or rely on Redis timestamps to avoid this.

Third: state management at scale. Storing a counter per user per endpoint per second sounds manageable until you have 10 million users and 500 endpoints. That's 5 billion keys. Your Redis memory will bleed. You need hierarchical aggregation (e.g., hash per user, not per endpoint) or probabilistic data structures like a counting Bloom filter.

Fourth: race conditions. Two requests arriving at the exact same microsecond can both increment a counter past the limit. Use Lua scripts in Redis for atomic operations or pessimistic locking. Optimistic approaches will leak traffic eventually.

Fifth: threshold effects. Users don't hit limits gradually — they hit them right at the boundary, then retry frantically. Without exponential backoff and jitter, you'll create a thundering herd on your own limiter. Your rate limiter will DDoS itself.

// io.thecodeforge — system-design tutorial

import time
import redis

# Atomic check-and-increment via Redis Lua script
SCRIPT = """
local current = redis.call('GET', KEYS[1])
if current and tonumber(current) >= tonumber(ARGV[1]) then
    return 0
end
redis.call('INCR', KEYS[1])
redis.call('EXPIRE', KEYS[1], 60)
return 1
"""

def check_rate_limit(user_id, max_requests, window_seconds=60):
    r = redis.Redis()
    key = f"rate_limit:{user_id}"
    allowed = r.eval(SCRIPT, 1, key, max_requests)
    return bool(allowed)

print(check_rate_limit("user_42", 5))  # First call
print(check_rate_limit("user_42", 5))  # Still within limit

# After 6 calls:
for _ in range(5):
    check_rate_limit("user_42", 5)
print(check_rate_limit("user_42", 5))  # Blocked