Rate limiting algorithms (token bucket, leaky bucket) in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Token Bucket Algorithm Behavior

Consider a token bucket rate limiter with a bucket capacity of 5 tokens and a refill rate of 1 token per second. Initially, the bucket is full. If 7 requests arrive instantly at time 0, how many requests will be allowed immediately?

A 2 requests allowed immediately, 5 requests rejected

B 7 requests allowed immediately

C 0 requests allowed immediately, all queued

D 5 requests allowed immediately, 2 requests rejected

💡 Hint

Think about how many tokens are available at the start and how many requests consume tokens.

The bucket starts full with 5 tokens. Each request consumes one token. So, 5 requests can be served immediately. The remaining 2 requests have no tokens and are rejected or delayed.

❓ Architecture

intermediate

Choosing Between Token Bucket and Leaky Bucket

You are designing an API gateway that needs to limit request bursts but also smooth out traffic spikes over time. Which rate limiting algorithm is more suitable?

A Token Bucket, because it allows bursts up to bucket capacity

B Leaky Bucket, because it allows bursts up to bucket capacity

C Leaky Bucket, because it allows unlimited bursts

D Token Bucket, because it enforces a fixed output rate regardless of bursts

💡 Hint

Consider which algorithm allows bursts and which smooths traffic strictly.

Token Bucket allows bursts up to the bucket capacity by accumulating tokens. Leaky Bucket enforces a fixed output rate, smoothing traffic but not allowing bursts.

❓ scaling

advanced

Scaling Rate Limiter for Distributed Systems

You need to implement a distributed rate limiter using the token bucket algorithm across multiple servers. What is the main challenge and best approach?

A Challenge: High memory usage; Approach: Store tokens locally on each server without synchronization

B Challenge: Synchronizing token counts; Approach: Use a centralized token store with atomic operations

C Challenge: Network latency; Approach: Use local caches and ignore synchronization

D Challenge: Token overflow; Approach: Increase bucket size infinitely

💡 Hint

Think about consistency of token counts across servers.

Distributed token bucket requires synchronizing token counts to avoid allowing more requests than the limit. A centralized store with atomic operations ensures consistency.

❓ tradeoff

advanced

Tradeoffs Between Token Bucket and Leaky Bucket

Which statement correctly describes a tradeoff between token bucket and leaky bucket algorithms?

A Token bucket allows bursty traffic but can cause uneven output; leaky bucket smooths output but rejects bursts

B Leaky bucket allows bursty traffic but can cause uneven output; token bucket smooths output but rejects bursts

C Both algorithms allow unlimited bursts but differ in refill rates

D Token bucket rejects all bursts; leaky bucket allows bursts up to bucket size

💡 Hint

Recall how each algorithm handles bursts and output rate.

Token bucket allows bursts by accumulating tokens, which can cause uneven output. Leaky bucket enforces a steady output rate, smoothing traffic but rejecting bursts.

❓ estimation

expert

Estimating Capacity for Rate Limiter with Token Bucket

You have a token bucket rate limiter with a bucket size of 100 tokens and a refill rate of 10 tokens per second. What is the maximum number of requests that can be served in a 15-second window assuming the bucket starts full and requests arrive uniformly?

A 100 requests

B 150 requests

C 250 requests

D 50 requests

💡 Hint

Calculate total tokens available: initial tokens plus tokens refilled over time.

Total tokens = initial bucket size (100) + refill rate (10 tokens/sec) * 15 seconds = 100 + 150 = 250 tokens, so 250 requests can be served.