Implement a rate limiter

shouldAllowRequest() that returns true if the incoming requests have arrived at a rate less than or equal to specified rate, false otherwise.
1. What if you don’t have to worry about bursts?
2. What if you want to handle burst?

💡Strategies for Solving This Problem

System Design Meets Algorithms

Got this at Stripe in 2024. It's part system design, part implementation problem. They want to see if you understand rate limiting patterns AND can code them.

The Problem

Limit how many requests a user can make in a time window. For example: max 100 requests per hour per user.

Approach 1: Fixed Window Counter

Count requests in fixed time buckets (like hourly buckets starting at :00).

Pros: Simple, memory efficient
Cons: Burst problem at window edges. User could make 100 requests at 10:59 and 100 more at 11:00.

Approach 2: Sliding Window Log

Store timestamp of each request. For new request, count how many timestamps fall within the last window.

Pros: Accurate, no burst problem
Cons: Memory intensive (O(n) per user where n is limit)

Approach 3: Sliding Window Counter

Hybrid approach. Use buckets but calculate weighted average based on time position in current window.

Pros: Good accuracy with low memory
Cons: More complex logic

Approach 4: Token Bucket

Give user tokens at fixed rate. Each request consumes a token. Allows short bursts but enforces average rate.

Pros: Flexible, handles bursts smoothly
Cons: Need background process to refill tokens

What I Used at Stripe

Started with fixed window (simplest). Interviewer asked about burst problem. Discussed sliding window log and token bucket. Implemented token bucket because Stripe needs to handle payment bursts during sales events.

Key question they asked: "How would this scale to millions of users?" Discussed Redis, sharding by user ID, and what happens during cache failures (fail open vs fail closed).

Scroll to Top