How Rate Limiting Leaky Bucket Works: Networking Explained

1. Introduction and Core Concepts

Rate limiting is a fundamental technique in networking and distributed systems used to control the amount of traffic or requests a system will accept over a given period. Among the most elegant and widely deployed rate limiting algorithms is the Leaky Bucket algorithm. Inspired by a simple physical analogy — a bucket with a small hole in the bottom — this algorithm provides a smooth, predictable method for shaping traffic and enforcing rate limits while allowing for some degree of burst tolerance.

The leaky bucket is classified as a traffic shaping algorithm. Unlike algorithms that simply reject traffic that exceeds a threshold, the leaky bucket smooths out bursts by queuing incoming requests and processing them at a constant, fixed rate. Imagine water pouring into a bucket at an irregular, bursty rate. The bucket has a finite capacity and leaks water at a constant rate through a hole at the bottom. If water arrives faster than it leaks, the bucket fills up. If it continues to arrive and the bucket is full, the excess water overflows and is discarded. This overflow corresponds to dropped packets, rejected API requests, or throttled traffic in a real system.

Understanding the rate limiting leaky bucket is essential for any network engineer, backend developer, or system designer. It is the backbone of Quality of Service (QoS) in routers, API gateway throttling, and protection against Distributed Denial of Service (DDoS) attacks. Its core promise is simple yet powerful: it guarantees a bounded output rate regardless of how bursty the input is, ensuring downstream systems are never overwhelmed. This makes it ideal for scenarios where stability and predictability are more important than immediately serving every single request.

Why Rate Limiting Matters

Without rate limiting, a single misbehaving client or a sudden spike in legitimate traffic can exhaust server resources, leading to cascading failures, increased latency for all users, and complete service outages. Rate limiting acts as a protective valve, ensuring fair resource allocation and maintaining service availability.

The leaky bucket is particularly valuable because it enforces a strict, long-term average rate while still permitting short-term bursts up to the bucket's capacity. This balance between strictness and flexibility is why it remains a cornerstone of networking algorithms decades after its introduction in the context of ATM networks and is now codified in standards for traffic policing and shaping.

2. How It Works

At its heart, the leaky bucket algorithm relies on two key parameters: bucket capacity (also called bucket size or burst size) and leak rate (also called drain rate or sustained rate). The capacity, measured in bytes, packets, or requests, determines the maximum burst that can be accommodated. The leak rate, measured in units per second, determines the constant rate at which the bucket drains and thus the long-term average rate of traffic that is allowed through.

The mechanism operates continuously over time. Conceptually, the system maintains a counter representing the current water level in the bucket. When a packet or request of size n arrives, the algorithm first calculates how much water has leaked since the last update. It does this by multiplying the leak rate by the elapsed time: leaked = leak_rate * (current_time - last_update_time). This amount is subtracted from the current water level, with a floor of zero. After the leak is applied, the algorithm checks if the new request would cause an overflow.

If current_level + n <= capacity, the request is considered conforming. The water level is increased by n, and the request is queued for processing or forwarded at the leak rate. If current_level + n > capacity, the request is non-conforming and is immediately discarded or rejected without adding water to the bucket. This decision is deterministic and requires no complex windowing logic, making the algorithm extremely efficient to implement in hardware and software.

The Queuing vs. Policing Distinction

It is important to distinguish between two modes of operation: traffic shaping and traffic policing. When used as a shaper, the leaky bucket queues non-conforming packets instead of dropping them, introducing delay to smooth the output to exactly the leak rate. This is common in outbound traffic shaping on routers. When used as a policer, it drops or marks non-conforming packets immediately, which is common for inbound rate limiting on APIs. The core mathematics remain identical; only the action taken on overflow differs.

Unlike the token bucket algorithm, which is often confused with the leaky bucket, the leaky bucket enforces a strictly smooth output. The token bucket allows bursts to pass through instantly as long as tokens are available, leading to a bursty output. The leaky bucket, by contrast, forces all output to be paced at the leak rate, resulting in a perfectly smooth stream. This makes it ideal for applications like audio/video streaming or network links where jitter must be minimized.

Key Parameters Explained

Choosing the correct capacity and leak rate is critical. A small capacity enforces a very strict limit with almost no burst tolerance, which can lead to excessive rejections for naturally bursty web traffic. A very large capacity allows large bursts, which may defeat the purpose of protecting downstream systems. Similarly, the leak rate must be tuned to the true sustainable capacity of the backend service. A rate that is too high offers no protection, while a rate that is too low artificially throttles legitimate users and wastes resources.

3. Implementation

Implementing the leaky bucket in software is straightforward and requires only a few variables and time-based calculations. The most accurate implementation is time-based, where the leak is calculated on-demand based on elapsed time, rather than using a background thread to periodically drain the bucket. This approach is more efficient and avoids concurrency issues associated with timers.

Below are several Python implementations demonstrating different aspects and use cases of the algorithm, from a basic single-threaded version to a thread-safe version suitable for production web servers.

# Basic Time-Based Leaky Bucket Implementation
import time

class LeakyBucket:
    """
    A simple leaky bucket rate limiter.
    capacity: maximum water (burst size) the bucket can hold
    leak_rate: rate at which water leaks (units per second)
    """
    def __init__(self, capacity: float, leak_rate: float):
        self.capacity = capacity
        self.leak_rate = leak_rate
        self.water = 0.0  # current water level
        self.last_update = time.monotonic()

    def _leak(self):
        """Calculate and apply leakage based on elapsed time."""
        now = time.monotonic()
        elapsed = now - self.last_update
        # Calculate leaked amount
        leaked = elapsed * self.leak_rate
        # Decrease water level, ensure it doesn't go below 0
        self.water = max(0.0, self.water - leaked)
        self.last_update = now

    def allow_request(self, amount: float = 1.0) -> bool:
        """
        Try to add 'amount' to the bucket.
        Returns True if request is allowed (conforming), False if rejected.
        """
        self._leak()
        # Check if adding would overflow the bucket
        if self.water + amount > self.capacity:
            return False  # Overflow - reject request
        
        self.water += amount
        return True  # Allowed

    def get_water_level(self) -> float:
        """Get current water level after applying leak."""
        self._leak()
        return self.water

# Thread-Safe Leaky Bucket for Concurrent Web Servers
import time
import threading

class ThreadSafeLeakyBucket:
    """
    Thread-safe leaky bucket using a lock.
    Suitable for multi-threaded environments like WSGI servers.
    """
    def __init__(self, capacity: float, leak_rate: float):
        self.capacity = capacity
        self.leak_rate = leak_rate
        self.water = 0.0
        self.last_update = time.monotonic()
        self.lock = threading.Lock()

    def _leak_locked(self):
        # Must be called with lock held
        now = time.monotonic()
        elapsed = now - self.last_update
        leaked = elapsed * self.leak_rate
        # Ensure water never goes negative
        if leaked > 0:
            self.water = max(0.0, self.water - leaked)
            self.last_update = now

    def consume(self, tokens: float = 1.0) -> bool:
        """
        Atomically try to consume tokens.
        Returns True on success, False if rate limit exceeded.
        """
        with self.lock:
            self._leak_locked()
            if self.water + tokens <= self.capacity:
                self.water += tokens
                return True
            else:
                return False

    def expected_wait_time(self, tokens: float = 1.0) -> float:
        """
        Calculate time (seconds) caller should wait before retrying.
        Useful for returning Retry-After headers.
        """
        with self.lock:
            self._leak_locked()
            if self.water + tokens <= self.capacity:
                return 0.0
            # How much excess water needs to leak?
            excess = (self.water + tokens) - self.capacity
            return excess / self.leak_rate

# Leaky Bucket as a Traffic Shaper (Queuing Version)
import time
import collections

class LeakyBucketShaper:
    """
    Leaky Bucket used as a shaper: queues requests and processes
    them at a constant leak rate instead of dropping immediately.
    """
    def __init__(self, capacity: int, leak_rate: float):
        self.capacity = capacity
        self.leak_rate = leak_rate  # packets per second
        self.queue = collections.deque()
        self.water = 0.0
        self.last_leak = time.monotonic()

    def _leak(self):
        now = time.monotonic()
        elapsed = now - self.last_leak
        leaked = elapsed * self.leak_rate
        self.water = max(0.0, self.water - leaked)
        self.last_leak = now
        # Also drain queued packets at leak rate
        # For simplicity, we model queue drain as water decrease

    def enqueue(self, packet) -> bool:
        """Try to enqueue a packet. Returns False if bucket is full (policing)."""
        self._leak()
        # Each packet counts as 1 unit of water
        if self.water + 1 > self.capacity:
            return False  # Drop packet - bucket full
        self.queue.append(packet)
        self.water += 1
        return True

    def dequeue(self):
        """
        Dequeue next packet at the leak rate.
        In a real system, this would be called by a timer every 1/leak_rate seconds.
        """
        self._leak()
        if self.queue and self.water >= 1:
            # Simulate leaking one packet worth of water when dequeuing
            # In a pure shaper, dequeue is rate-limited, not water-limited
            return self.queue.popleft()
        return None

    def size(self) -> int:
        self._leak()
        return len(self.queue)

# Simulation: Comparing Leaky Bucket Behavior with Bursty Traffic
import time

def simulate_leaky_bucket():
    """Simulate bursty traffic against a leaky bucket."""
    bucket = LeakyBucket(capacity=10, leak_rate=2)  # 2 requests/sec, burst 10
    # Simulate requests arriving at different times: (delay_since_start, num_requests)
    traffic_pattern = [
        (0.0, 5),   # t=0.0: 5 requests burst
        (0.1, 5),   # t=0.1: another 5 burst (total 10, bucket fills)
        (0.2, 2),   # t=0.2: 2 more requests should be rejected
        (1.0, 2),   # t=1.0: after ~1 sec, 2 units leaked, so 2 allowed
        (3.0, 8),   # t=3.0: after 2 more secs, 4 units leaked, 8 will partially fail
    ]
    
    start = time.monotonic()
    # Mock time for deterministic simulation
    bucket.last_update = start
    
    print(f"Bucket: capacity={bucket.capacity}, leak_rate={bucket.leak_rate}/sec")
    for delay, count in traffic_pattern:
        # Fast-forward time
        bucket.last_update = start  # reset for simple calc
        # Manually set elapsed for demo; in real code time passes naturally
        # Here we simulate by adjusting water directly for clarity
        elapsed = delay
        leaked = elapsed * bucket.leak_rate
        # This is a simplified simulation loop
        allowed = 0
        rejected = 0
        for _ in range(count):
            # We need to re-calculate leak before each request in burst
            # For this demo, we approximate
            if bucket.allow_request(1):
                allowed += 1
            else:
                rejected += 1
        print(f"t={delay:.1f}s: {count} requests -> Allowed: {allowed}, Rejected: {rejected}, Water: {bucket.get_water_level():.2f}")

# Note: For a precise simulation, use a mock clock or sleep.
# The key takeaway is that after the bucket fills, further requests are rejected
# until enough time has passed for the bucket to leak.

4. Step-by-Step Example

To make the abstract mechanism concrete, let us walk through a detailed example. Consider a leaky bucket configured for an API endpoint with a capacity of 10 requests and a leak rate of 2 requests per second. This configuration allows a maximum burst of 10 requests at once, but sustains a long-term average of only 2 requests per second. We will track the water level over time as bursty traffic arrives.

At time T=0.0 seconds, the bucket is empty (water = 0). Five requests arrive simultaneously. The algorithm first calculates leakage: elapsed time is 0, so leaked is 0. It checks each request sequentially. The first five requests all find that water + 1 <= 10, so they are all accepted. After processing, water = 5. The API has handled the initial burst gracefully.

At T=0.2 seconds, just 200 milliseconds later, another burst of 7 requests arrives. Before processing, the bucket leaks: elapsed = 0.2, leaked = 0.2 * 2 = 0.4. The water level drops from 5 to 4.6. Now the first 5 requests of the new burst are accepted, bringing water to 9.6. The 6th request would bring water to 10.6, which exceeds the capacity of 10, so it is rejected. The 7th request is also rejected. The bucket is now nearly full, and the client receives two 429 Too Many Requests errors, signaling it to slow down.

At T=2.2 seconds, two seconds have passed since the last burst. The bucket has leaked 2.0 * 2 = 4.0 units. Water drops from 9.6 to 5.6. Now, if 3 new requests arrive, they will be accepted (5.6 -> 6.6 -> 7.6 -> 8.6). The system has recovered and can accept more traffic. This demonstrates the core property: the bucket smooths traffic to an average of 2 requests per second, but its capacity of 10 allows it to absorb short bursts without immediately penalizing the client. If traffic had continued at a rate higher than 2 requests per second indefinitely, the bucket would remain full and most requests would be rejected, effectively enforcing the rate limit.

Visualizing the Water Level

If we plotted water level versus time, we would see a sawtooth pattern: sharp upward jumps when bursts arrive, followed by steady linear declines at a slope of -2 units per second. The horizontal line at water=10 represents the ceiling. Any attempted jump that would cross this ceiling is truncated and rejected. This visualization is invaluable for tuning parameters: if the water level is constantly at the ceiling, your leak rate is too low for the offered load; if it is almost always near zero, your limits may be too lenient.

5. Complexity Analysis

One of the greatest strengths of the leaky bucket algorithm is its exceptional computational efficiency. Unlike sliding window log algorithms that must store timestamps for every request, the leaky bucket requires only constant time and constant space per operation, making it suitable for implementation at the highest speeds in network hardware and for high-throughput software rate limiters.

Each request requires only a few arithmetic operations: calculating elapsed time, multiplying by the leak rate, a subtraction, and a comparison. There are no loops, no data structure traversals, and no memory allocations in the critical path. This O(1) time complexity holds for all cases — best, average, and worst — because the amount of work does not depend on the number of previous requests or the current water level.

Space complexity is also O(1). The algorithm's state consists of just three or four scalar values: capacity, leak_rate, water level, and last_update timestamp, plus an optional lock for thread safety. This is independent of the request rate or burst size. In contrast, a sliding window counter might need to store multiple window counts, and a sliding window log stores one entry per request in the window, leading to O(N) space where N is the number of requests in the window.

When used as a shaper with a queue, the space complexity becomes O(Q) where Q is the number of queued packets, bounded by the capacity. However, the rate limiting decision itself remains O(1). This efficiency explains why the leaky bucket is often implemented directly in ASICs on network switches and routers, where it can police traffic at line rates of tens or hundreds of gigabits per second without becoming a bottleneck.

It is worth noting that while the basic algorithm is O(1), a distributed implementation that shares state across multiple servers (e.g., using Redis) will incur network latency. The local computation remains O(1), but the overall request latency will be dominated by the round-trip time to the centralized store, typically O(network). Careful design using local buckets with periodic synchronization can mitigate this.

6. Variations and Optimizations

While the classic leaky bucket is simple and effective, several variations and optimizations have been developed to address its limitations and adapt it to modern distributed systems.

The most common variant is the Token Bucket, which is often considered the inverse of the leaky bucket. In a token bucket, tokens are added at a fixed rate up to a capacity, and each request consumes a token. This allows for bursty output, as requests can pass instantly if tokens are available. Many systems marketed as "leaky bucket" are actually token buckets because the token bucket is more permissive for bursty web traffic. Understanding the distinction is crucial: use leaky bucket when you need smooth, paced output; use token bucket when you want to allow bursts but limit the average rate.

Another important optimization is the Distributed Leaky Bucket. In a microservices architecture with multiple API gateway instances, a single in-memory bucket per instance would allow N times the intended rate (where N is the number of instances). To enforce a global limit, state must be shared. Common approaches include using a centralized data store like Redis with atomic operations (using Lua scripts to ensure the leak calculation and check are atomic) or using a consensus-based approach with eventual consistency and local buckets that sync periodically. The Redis-based approach provides strong consistency but adds latency, while the local-bucket approach is faster but allows temporary overages.

For handling variable-sized requests, the algorithm is easily extended to a byte-based or weighted bucket. Instead of amount = 1 per request, the amount is the size of the packet in bytes or a cost weight assigned to different API endpoints. For example, a GET /users might cost 1 token, while an expensive POST /reports might cost 10 tokens. This allows for more nuanced rate limiting that reflects the actual load on backend resources rather than just request count.

Adaptive and Hierarchical Buckets

Adaptive leaky buckets dynamically adjust their leak rate based on backend health. If downstream latency increases or error rates spike, the leak rate is automatically reduced to shed load. This creates a feedback loop that provides self-protection. Hierarchical buckets are also used, where a global bucket limits total traffic and per-user or per-IP buckets provide fair sharing. A request must pass both buckets to be allowed, enabling sophisticated policies like "1000 requests per second globally, but no more than 10 per second per IP."

7. Real-World Applications

The leaky bucket algorithm is not a theoretical curiosity; it is deployed in countless production systems that handle internet-scale traffic every day. Its predictability and efficiency make it a go-to choice across the networking stack.

In networking hardware, leaky bucket policing is a core part of Quality of Service (QoS). Internet Service Providers (ISPs) use it to enforce Service Level Agreements (SLAs) for business customers. A customer who pays for a 100 Mbps committed rate will have their traffic policed by a leaky bucket: traffic conforming to the rate is forwarded with high priority, while excess traffic is dropped or marked as lower priority. Similarly, in data center switches, it is used to prevent a single tenant from saturating a shared link.

In software, API gateways and web servers are the most visible users. Services like AWS API Gateway, Kong, Nginx, and Cloudflare all offer leaky bucket (or token bucket) based rate limiting. For example, an API might be configured to allow 100 requests per minute per API key. The leaky bucket ensures that a client cannot make 100 requests in the first second and then starve others; instead, it smooths usage and returns HTTP 429 responses with a Retry-After header when the bucket is full, guiding clients to implement exponential backoff.

Beyond these, the leaky bucket is used for protecting databases from connection storms, limiting outbound email sending to avoid being flagged as spam, controlling the rate of background jobs and web crawlers, and even in operating systems to limit the rate of log messages (e.g., printk rate limiting in the Linux kernel) to prevent log flooding from overwhelming the system.

8. Comparison with Alternatives

Choosing the right rate limiting algorithm depends on your specific requirements for burst handling, memory usage, accuracy, and output smoothness. The leaky bucket is one of four major families, each with distinct trade-offs.

The Fixed Window Counter is the simplest alternative: it divides time into fixed windows (e.g., one minute) and counts requests per window. It is easy to implement but suffers from a critical burst problem at window boundaries — a client can make limit requests at the end of one window and limit requests at the start of the next, effectively doubling the rate for a short period. The Sliding Window Log fixes this by storing a timestamp for every request and counting requests in a rolling window, providing perfect accuracy but at O(N) memory cost. The Sliding Window Counter is a hybrid that combines fixed windows with a weighted count from the previous window, offering a good balance of accuracy and efficiency.

The Token Bucket, as mentioned, is the closest relative to the leaky bucket. Both use the concepts of capacity and rate, but their behavior is inverted. The token bucket adds tokens at a fixed rate and allows bursts to pass immediately, making it a traffic policer that permits bursts. The leaky bucket drains at a fixed rate and smooths bursts, making it a traffic shaper that enforces smoothness. If your downstream system can handle bursts but you want to limit the average rate, use token bucket. If your downstream system requires a smooth, constant rate, use leaky bucket.

In practice, many large-scale systems use a combination. For instance, Cloudflare uses a leaky bucket for DDoS mitigation at the edge (to smooth massive traffic spikes) and a token bucket or sliding window for per-customer API rate limiting (to allow legitimate bursts while preventing abuse).

9. Common Mistakes and Best Practices

Implementing rate limiting correctly is deceptively difficult. A flawed implementation can be worse than no rate limiting at all, either by failing to protect the system or by unfairly throttling legitimate users. Here are the most common pitfalls and how to avoid them.

A frequent mistake is using wall-clock time (time.time()) instead of monotonic time (time.monotonic()). Wall-clock time can jump forward or backward due to NTP adjustments or daylight saving changes, causing the bucket to leak an incorrect amount — potentially emptying instantly or never leaking. Always use a monotonic clock for measuring elapsed intervals. Another critical error is forgetting to make the check-and-update operation atomic. In a concurrent environment, two threads might both check water + 1 <= capacity simultaneously, both see it as true, and both add water, causing the bucket to overflow. This race condition requires a lock, atomic compare-and-swap, or a Lua script in Redis to prevent.

Choosing inappropriate parameters is another common failure. Setting the capacity too small (e.g., 1) turns the leaky bucket into a strict fixed-rate limiter with no burst tolerance, which breaks many clients that naturally send small bursts (e.g., a web page loading 10 assets at once). Setting the leak rate without considering the actual capacity of downstream dependencies leads to either ineffective protection or unnecessary throttling. Best practice is to load test your backend to find its sustainable throughput, set the leak rate to 80-90% of that value, and set capacity to allow a reasonable burst (e.g., 2-5 seconds worth of traffic at the leak rate).

Poor client experience is often overlooked. Simply dropping requests without informative feedback forces clients to guess. Always return a clear HTTP 429 status code with headers like Retry-After (seconds to wait), X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. This allows well-behaved clients to implement exponential backoff and retry logic. Furthermore, avoid applying a single global bucket to all users; this allows one abusive user to consume the entire capacity and starve others. Use per-key buckets (per IP, per user ID, per API key) for fair isolation.

Best Practices Checklist

• Use monotonic time for all elapsed calculations to avoid clock skew bugs.
• Ensure atomicity for the leak-check-update sequence using locks or atomic datastore operations.
• Tune capacity and leak rate based on real load testing, not guesswork. Monitor water level metrics.
• Implement per-client buckets rather than a single global bucket for fairness.
• Return standard rate limit headers and 429 responses to guide client retry behavior.
• Consider a two-tier approach: a fast local in-memory bucket for coarse limiting and a distributed bucket for precise global enforcement.
• Log and alert on rate limit rejections to detect abuse or misconfigured clients early.
• Document your rate limiting policy clearly for API consumers, including limits and burst allowances.

10. Interview Questions

Rate limiting is a favorite topic in system design and networking interviews. Interviewers use it to assess your understanding of distributed systems, trade-offs, and practical implementation details. Here are common questions and how to approach them.

Q1: Explain the difference between Leaky Bucket and Token Bucket. When would you use each?

This tests your conceptual clarity. Answer: Both control rate using capacity and rate, but they are opposites. Leaky bucket has a constant output rate — it smooths bursts by queuing or dropping excess and is used for traffic shaping where a smooth output is required (e.g., video streaming, network QoS). Token bucket has a bursty output — it allows bursts up to capacity instantly if tokens are available and is used for policing where you want to allow bursts but limit the average rate (e.g., API rate limiting). Mention that leaky bucket enforces a hard limit on output rate, while token bucket enforces a limit on input rate.

Q2: How would you implement a distributed rate limiter for a cluster of 10 API servers handling 10,000 requests per second?

This is a system design question. A strong answer discusses the need for a global limit and proposes a solution using Redis with a Lua script to atomically execute the leaky bucket logic (leak calculation + check + update). Discuss trade-offs: centralized Redis adds latency (~1-2ms) but provides strong consistency; alternative is local buckets with periodic sync via gossip or eventual consistency, which is faster but allows temporary over-limit. Mention optimizations like batching, using Redis Cluster for scalability, and handling Redis failure (fail-open vs. fail-closed). Also mention adding per-user buckets using Redis hashes.

Q3: What happens if the leak rate is higher than the arrival rate? What if the capacity is set to zero?

This tests edge cases. If leak rate > arrival rate, the bucket will almost always be empty (water near 0), and nearly all requests will be allowed. The rate limiter is effectively not limiting. If capacity is zero, no burst is allowed and no water can be held; every request would require the bucket to be completely empty at that exact instant. In practice, capacity must be at least 1 (or at least the size of one request) to allow any traffic. A capacity of zero would reject all requests.

Q4: How do you handle clock drift in a distributed leaky bucket implementation?

This probes deep understanding. Answer: Never rely on synchronized wall clocks across servers. Instead, store last_update timestamp in the centralized store (Redis) and calculate elapsed time on the server that processes the request using the stored timestamp and its own monotonic clock, or use Redis server time (TIME command) as the source of truth. The Lua script should use Redis time to avoid client clock skew. Also mention using monotonic time locally and that small drift is tolerable because the algorithm is based on elapsed intervals, not absolute time.

Q5: Design a rate limiter that allows 100 requests per minute per user, but also enforces a global limit of 1000 requests per second across all users.

This tests hierarchical limiting. Answer: Use two leaky buckets per request: a per-user bucket (capacity 100, leak rate 100/60 ≈ 1.66 req/sec) and a global bucket (capacity 1000, leak rate 1000 req/sec). A request is allowed only if both buckets allow it. Implement this atomically (e.g., in a single Redis Lua script that checks both buckets). Discuss failure modes: if global bucket is full, all users are throttled even if their personal bucket has space. Mention that this provides both fairness (per-user) and protection (global).

Mastering these questions requires not just memorizing definitions but understanding the underlying trade-offs in time complexity, space complexity, burst behavior, and distributed consistency. The leaky bucket's elegant simplicity makes it a powerful tool, but knowing when not to use it — and what to use instead — is what distinguishes a senior engineer.