Implement a Per-IP Sliding Window Rate Limiter

Quick Overview

This Ramp software engineering question evaluates implementation of a per-IP sliding window rate limiter. It prepares candidates to discuss time-window data structures, memory cleanup, concurrency concerns, and operational behavior under traffic spikes.

Implement a Per-IP Sliding Window Rate Limiter

Company: Ramp

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Technical Screen

Given sorted request timestamps, matching IP addresses, a request limit, and a time-window length, return an array where `1` means the request is accepted and `0` means it is rejected. For each IP, at most `limit` accepted requests may occur within any window of length `timeWindow`. ### Constraints & Assumptions - Timestamps are sorted in nondecreasing order. - The window is per IP address. - Rejected requests should not count against future accepted-request limits. - Return one decision per input request. ### Clarifying Questions to Ask - Is the time window inclusive on both ends or half-open? - Should rejected requests be tracked at all? - Can multiple requests from the same IP share a timestamp? - What are the input size limits? - Are IPs strings or numeric ids? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How would this run in a distributed system? - How would you implement token bucket instead? - How would memory be bounded for many inactive IPs? - How would you explain rejected versus accepted request accounting?

Quick Answer: This Ramp software engineering question evaluates implementation of a per-IP sliding window rate limiter. It prepares candidates to discuss time-window data structures, memory cleanup, concurrency concerns, and operational behavior under traffic spikes.

|Home/Software Engineering Fundamentals/Ramp
Ramp logo
Ramp
Jul 2, 2026, 7:02 PM
mediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
16
0

Given sorted request timestamps, matching IP addresses, a request limit, and a time-window length, return an array where 1 means the request is accepted and 0 means it is rejected. For each IP, at most limit accepted requests may occur within any window of length timeWindow.

Constraints & Assumptions

  • Timestamps are sorted in nondecreasing order.
  • The window is per IP address.
  • Rejected requests should not count against future accepted-request limits.
  • Return one decision per input request.

Clarifying Questions to Ask Guidance

  • Is the time window inclusive on both ends or half-open?
  • Should rejected requests be tracked at all?
  • Can multiple requests from the same IP share a timestamp?
  • What are the input size limits?
  • Are IPs strings or numeric ids?

What a Strong Answer Covers Premium

Follow-up Questions Guidance

  • How would this run in a distributed system?
  • How would you implement token bucket instead?
  • How would memory be bounded for many inactive IPs?
  • How would you explain rejected versus accepted request accounting?
Loading comments...