Design a rate limiter in HLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define the main component responsible for limiting requests.

HLD

class [1]Limiter:
    def __init__(self, max_requests, window_seconds):
        self.max_requests = max_requests
        self.window_seconds = window_seconds
        self.requests = {}  # user_id -> list of timestamps

Drag options to blanks, or click blank then click option'

ARate

BRequest

CLimit

DThrottle

Attempts:

3 left

💡 Hint

Common Mistakes

Using generic names like 'RequestLimiter' which is less common.

Using 'Throttle' which is related but not the standard class name.

The main class is commonly called RateLimiter as it controls the rate of requests.

2fill in blank

medium

Complete the code to check if a user can make a request within the rate limit window.

HLD

def is_allowed(self, user_id, current_time):
    if user_id not in self.requests:
        self.requests[user_id] = []
    self.requests[user_id] = [t for t in self.requests[user_id] if t > current_time - [1]]
    return len(self.requests[user_id]) < self.max_requests

Drag options to blanks, or click blank then click option'

Aself.window_seconds

Bself.max_requests

Ccurrent_time

Duser_id

Attempts:

3 left

💡 Hint

Common Mistakes

Using max_requests instead of window_seconds for filtering timestamps.

Using current_time directly without subtracting the window.

The window to keep requests is defined by self.window_seconds, which is the time frame for rate limiting.

3fill in blank

hard

Fix the error in the code that adds a new request timestamp after checking allowance.

HLD

def add_request(self, user_id, current_time):
    if self.is_allowed(user_id, current_time):
        self.requests[user_id].[1](current_time)
        return True
    return False

Drag options to blanks, or click blank then click option'

Aadd

Bappend

Cinsert

Dextend

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'add' which is for sets, not lists.

Using 'extend' which expects an iterable, not a single element.

To add a single timestamp to the list, use append. Other methods are incorrect for this purpose.

4fill in blank

hard

Fill both blanks to implement a sliding window rate limiter that removes old requests and checks the count.

HLD

def is_allowed(self, user_id, current_time):
    self.requests[user_id] = [t for t in self.requests.get(user_id, []) if t [1] current_time - self.window_seconds]
    return len(self.requests[user_id]) [2] self.max_requests

Drag options to blanks, or click blank then click option'

A>

B<

C>=

D<=

Attempts:

3 left

💡 Hint

Common Mistakes

Using '>=' instead of '>' which may keep one extra old timestamp.

Using '>=' or '>'' for the count comparison which would block one extra request.

We keep timestamps greater than the window start (t > current_time - window) and allow if count is less than max_requests.

5fill in blank

hard

Fill all three blanks to implement a dictionary comprehension that tracks request counts per user within the window.

HLD

request_counts = {user: len([t for t in times if t [1] current_time - window]) for user, times in [2].items() if len(times) [3] 0}

Drag options to blanks, or click blank then click option'

A>

Brequests

Dself.requests

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'requests' instead of 'self.requests' which is undefined in this scope.

Using '>=' instead of '>' which may include old timestamps.

Using 'len(times) >=' 0 which is always true and unnecessary.

We filter timestamps greater than the window start, iterate over self.requests, and only include users with more than zero requests.

Practice

1. What is the primary purpose of a rate limiter in system design?

easy

A. To control the number of requests a user can make in a given time

B. To increase the speed of database queries

C. To store user data securely

D. To balance load between multiple servers

Solution

1. Step 1: Understand the role of rate limiter

   A rate limiter restricts how many requests a user or client can send in a certain time to prevent overload.

2. Step 2: Identify the correct purpose

   Among the options, only controlling request rate matches the rate limiter's function.

3. Final Answer:

   To control the number of requests a user can make in a given time -> Option A

4. Quick Check:

   Rate limiter = control request rate [OK]

Hint: Rate limiter limits requests per time window [OK]

Common Mistakes:

• Confusing rate limiter with load balancer
• Thinking it speeds up database queries
• Assuming it stores user data

2. Which data structure is most suitable to implement a sliding window rate limiter?

easy

A. Stack

B. Hash Map

C. Queue

D. Binary Tree

Solution

1. Step 1: Recall sliding window mechanism

   Sliding window rate limiter tracks timestamps of requests in a time window, removing old ones as time moves.

2. Step 2: Choose data structure for efficient insert and remove

   A queue allows adding new timestamps at the end and removing old timestamps from the front efficiently, matching sliding window needs.

3. Final Answer:

   Queue -> Option C

4. Quick Check:

   Sliding window = queue for timestamps [OK]

Hint: Sliding window needs FIFO structure like queue [OK]

Common Mistakes:

• Using stack which is LIFO, not suitable
• Choosing hash map without order
• Picking binary tree which is complex here

3. Consider a rate limiter allowing 3 requests per 10 seconds using sliding window. If requests come at seconds 1, 3, 7, and 9, which request will be rejected?

medium

A. Request at second 9

B. Request at second 3

C. Request at second 7

D. Request at second 1

Solution

1. Step 1: Track requests in 10-second window

   Requests at 1, 3, 7 are allowed as they are within limit 3 per 10 seconds.

2. Step 2: Check request at second 9

   At second 9, previous requests at 1, 3, 7 are still within 10 seconds window (from -1 to 9). So 3 requests already made, this 4th request exceeds limit and is rejected.

3. Final Answer:

   Request at second 9 -> Option A

4. Quick Check:

   4th request in 10s window = rejected [OK]

Hint: Count requests in last 10 seconds; 4th exceeds limit [OK]

Common Mistakes:

• Ignoring requests older than 10 seconds
• Allowing all requests without limit
• Counting requests incorrectly

4. A rate limiter uses a fixed window counter but sometimes allows bursts of requests at window edges. What is the likely cause?

medium

A. Sliding window algorithm is used

B. Queue data structure is not used

C. Rate limit is set too low

D. Fixed window resets counters abruptly causing bursts

Solution

1. Step 1: Understand fixed window behavior

   Fixed window counts requests in fixed intervals, resetting count at window end.

2. Step 2: Identify burst cause

   Requests near end of one window and start of next can both be allowed, causing bursts.

3. Final Answer:

   Fixed window resets counters abruptly causing bursts -> Option D

4. Quick Check:

   Fixed window reset causes bursts [OK]

Hint: Fixed window resets cause bursts at edges [OK]

Common Mistakes:

• Confusing sliding window with fixed window
• Blaming rate limit value instead of algorithm
• Ignoring window reset behavior

5. You need to design a distributed rate limiter for millions of users with low latency. Which approach best balances accuracy and scalability?

hard

A. Centralized fixed window counter on a single server

B. Distributed sliding window using local caches and periodic sync

C. Per-user token bucket stored only in client devices

D. No rate limiting, rely on server hardware scaling

Solution

1. Step 1: Consider scalability and accuracy needs

   Millions of users require distributed design to avoid bottlenecks and reduce latency.

2. Step 2: Evaluate options

   Centralized fixed window causes bottleneck; client-only token bucket is insecure; no rate limiting risks overload. Distributed sliding window with local caches and sync balances accuracy and scalability.

3. Final Answer:

   Distributed sliding window using local caches and periodic sync -> Option B

4. Quick Check:

   Distributed sliding window = scalable + accurate [OK]

Hint: Use distributed sliding window with local caches [OK]

Common Mistakes:

• Choosing centralized approach causing bottlenecks
• Relying on client-only enforcement
• Ignoring rate limiting and risking overload