coding
Snowflake
Databricks
Amazon

Rate Limiter Dropped Requests (Coding) - Snowflake

Topics:
Sliding Window
Rate Limiting
Simulation
Roles:
Software Engineer
Backend Engineer
Site Reliability Engineer
Experience:
Entry Level
Mid Level
Senior

Question Description

Problem overview

You are given a list of integer arrival timestamps (seconds) in arrival order. For each request, you must decide if the request is processed or dropped by a rate limiter that enforces two hard limits: at most 3 requests per second and at most 20 requests per 10 seconds. Windows are inclusive: the per-second window is [t, t] and the ten-second window is [t-9, t] for a request at time t.

What you'll be asked to do

Simulate the rate limiter and return the timestamps of requests that are dropped, in the same order they appear. The interviewer will expect you to handle multiple requests at the same second, contiguous bursts, and sparse arrivals. You'll typically be guided through an approach, asked to optimize for time/space, and to discuss edge cases and complexity.

How to think about it (high level)

  • Model the problem as a simulation using sliding-window counting rather than per-request heavy recomputation.
  • Use a queue/deque or two-pointer technique to efficiently count requests inside the relevant windows (current second and last 10 seconds) as you iterate.
  • Maintain counters for the current second and a structure (deque or indexed counts) for the 10-second window; drop a request if either limit would be exceeded.

Skill signals

You should demonstrate: simulation of constraints, sliding-window or two-pointer counting, appropriate data structures (deque, arrays, hash maps), correctness on edge cases (many equal timestamps), and time/space complexity analysis (aim for O(n) time, O(k) extra space).

Common Follow-up Questions

  • How would you modify your solution to enforce the same limits per user/IP (i.e., per-key rate limiting) while keeping overall performance?
  • Replace the hard rules with a token-bucket or leaky-bucket algorithm—how does the implementation change and how do you support bursts?
  • How would you handle a sliding-window limit for a different granularity (e.g., 100 requests per minute and 1000 per hour) and keep O(n) runtime?
  • If arrival_times is a massive streaming log (too large for memory), how would you detect dropped requests in a single pass with limited memory?
  • What are the exact time and space complexities of your solution, and how would you optimize if the 10-second window limit changed frequently at runtime?

Related Questions

1Implement a token bucket rate limiter and explain trade-offs versus fixed-window counting
2Design a per-user rate limiter (scale to millions of users) — architecture and data structures
3Sliding window counter problems: count items in last k seconds with O(1) amortized update
4Given request timestamps, return which seconds exceed a threshold (sliding window maximum/count)
5Throttling logs: detect when an endpoint is overwhelmed and report top offending IPs

Explore More Questions

Practice This Question with AI

Get real-time hints, detailed requirements, and insightful analysis of the question.

Rate Limiter Dropped Requests - Snowflake | Voker