HTTP & API Rate Limiting Interview Questions
Reviewed by Mark Dickie · Last updated
Rate limiting is a technique that controls how many requests a client can send to an API within a given time window, protecting backend services from abuse and overload. For an interview focused on HTTP and API security, you should know the common algorithms (token bucket, leaky bucket, fixed window, sliding window), the HTTP status codes involved (429 Too Many Requests with Retry-After), where rate limiting sits in the request lifecycle (edge / API gateway vs application layer), and the trade-offs of distributed rate limiting using shared stores like Redis.
Most rate-limiting interviews test whether you can pick the right algorithm for a given constraint and explain how you would enforce limits across multiple server instances. Examiners also check that you understand the difference between throttling and rejecting, and when to return a 429 versus a 503.
| Algorithm | How it works | Best for | Weakness |
|---|---|---|---|
| Token bucket | Tokens refill at a fixed rate; each request consumes one | Bursty traffic with an average rate ceiling | Hard to reason about exact per-second limits under bursts |
| Leaky bucket | Requests enter a queue and drain at a constant rate | Smoothing traffic to a steady output rate | Queue can grow unbounded if input exceeds drain rate |
| Fixed window | Counter resets at each interval boundary | Simple implementation, low memory | Burst at window edges (two bursts in quick succession) |
| Sliding window | Weighted overlap of current and previous window | More accurate than fixed window | Slightly more computation and memory per key |
What does a rate-limiting interview typically test?
- Choosing an algorithm based on requirements (burst tolerance, fairness, memory cost).
- Designing a distributed limiter that stays consistent across nodes, often with Redis or a shared counter.
- Returning correct HTTP semantics:
429 Too Many Requests,Retry-Afterheader, andX-RateLimit-*headers. - Handling client-side throttling and exponential backoff with jitter.
- Identifying per-user, per-IP, and per-endpoint granularity and when to combine them.
How do you enforce rate limits across multiple API servers?
A single-server counter is straightforward, but production APIs run behind load balancers with many instances. The common approach is to store counters in a shared, low-latency data store such as Redis, using atomic operations like INCR with EXPIRE or a Lua script to keep reads and writes consistent. You trade a small network round-trip for correctness; some systems accept eventual consistency and use local counters synced periodically to cut that cost. The key interview point is naming the consistency-vs-performance trade-off explicitly and justifying your choice.
Key facts
- Tarmac's HTTP & APIs interview questions cover 11 questions at difficulty 1–5 of 5.
- Tarmac tracked 4,906 job postings asking for HTTP & APIs in August 2026.
- Roles asking for HTTP & APIs advertise a median base salary of US$165,000, across 756 job postings as of August 2026.
- Tarmac last reviewed these HTTP & APIs interview questions on 31 August 2026.
At a glance
| Questions | 11 |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | True / false, Fill in the blank, Multiple choice, Multiple answer, Short answer, Code output |
What you'll review
- rate limiting
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
HTTP & APIs/api-security/rate-limiting
Rate limiting protects an API only from malicious (intentional) abuse and provides no benefit against accidental denial-of-service caused by buggy clients.#
Options
Show answer
This is false. Rate limiting protects an API from both malicious abuse and accidental overloads. A buggy client caught in an infinite retry loop can cause the same denial-of-service effect as a deliberate attack. By capping request rates for all callers, rate limiting preserves API availability no matter the cause of excessive traffic.
Rate limiting is effective against both intentional attacks (e.g., DDoS, credential stuffing) AND accidental overloads (e.g., a buggy client stuck in an infinite retry loop). By capping request rates for any caller, the API remains available regardless of whether excessive traffic is deliberate or unintentional.
HTTP & APIs/api-security/rate-limiting
When a rate-limited API response is returned, the server commonly includes the response header _____ to tell the client how many seconds (or a date/time) to wait before making another request.#
Show answer
When a rate-limited API response is returned, the server commonly includes the response header Retry-After to tell the client how many seconds (or a date/time) to wait before making another request.
The Retry-After HTTP response header (defined in RFC 7231 and used with 429 responses per RFC 6585) tells the client either a number of seconds to wait or an HTTP-date after which it may retry. This prevents clients from hammering the server immediately after being rate-limited and helps implement polite back-off behaviour.
HTTP & APIs/api-security/rate-limiting
A client sends too many requests to a REST API and the server enforces rate limiting. Which HTTP status code should the server return to indicate the client has exceeded its rate limit?#
Options
Show answer
The correct status code is 429 Too Many Requests (defined in RFC 6585). This code specifically signals that the client has exceeded the server's rate limit. It is often paired with a Retry-After header so the client knows when it may resume sending requests. Codes like 503 indicate server-side unavailability, not a client-side quota breach.
HTTP 429 Too Many Requests is the standard status code (defined in RFC 6585) used when a client has sent more requests than the server's rate limit allows. 400 signals a malformed request, 401 signals missing/invalid authentication, and 503 signals that the server itself is temporarily unavailable — none of these correctly convey rate-limiting semantics. Servers typically also include a Retry-After header alongside 429 to tell clients when they may try again.
HTTP & APIs/api-security/rate-limiting
Rate limiting can be implemented using different algorithms. The _____ algorithm maintains a counter per fixed time window and resets it when the window expires, while the _____ algorithm smooths out request bursts by processing requests at a constant outgoing rate.#
Show answer
Rate limiting can be implemented using different algorithms. The fixed window algorithm maintains a counter per fixed time window and resets it when the window expires, while the leaky bucket algorithm smooths out request bursts by processing requests at a constant outgoing rate.
The fixed window algorithm divides time into fixed intervals (e.g., every 60 seconds), keeps a request counter per window, and rejects requests once the counter exceeds the limit. It is simple but can allow burst traffic at window boundaries. The leaky bucket algorithm queues incoming requests and drains them at a steady rate, effectively smoothing out bursts and enforcing a consistent throughput. Other common algorithms include the sliding window log, sliding window counter, and token bucket.
HTTP & APIs/api-security/rate-limiting
An API gateway applies rate limiting to protect backend services. Which of the following HTTP response headers are standard or widely-accepted conventions for communicating rate-limit information to clients?#
Options
Pick every one that applies.
Show answer
The standard/widely-accepted rate-limit response headers are X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, and Retry-After. The first three are the de-facto industry convention (used by GitHub, Stripe, etc.) for exposing quota details, while Retry-After is an official IETF header (RFC 9110) paired with 429 Too Many Requests to tell clients when they may retry. X-Throttle-Queue-Depth is not a recognised standard.
X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset are the de-facto industry standard headers (used by GitHub, Twitter/X, Stripe, etc.) for conveying the rate-limit quota, remaining calls, and window-reset time respectively. Retry-After is an official IETF header (RFC 7231 / 9110) returned with 429 Too Many Requests to tell clients when to retry. X-Throttle-Queue-Depth is not a recognised standard or widely-adopted convention — it was a distractor.
HTTP & APIs/api-security/rate-limiting
A distributed API gateway runs on 10 identical nodes behind a load balancer. A rate limit of 100 requests per minute per user is configured using a local in-memory counter on each node. Traffic is distributed roughly evenly across nodes.#
Show answer
Because each node maintains its own independent in-memory counter, a user can make up to 100 requests per minute to EACH of the 10 nodes — effectively allowing 1,000 requests per minute per user instead of 100. The counters are not shared, so no single node knows the global request count. A common solution is to use a centralised distributed store (e.g., Redis) with atomic operations (INCR + EXPIRE, or the sliding-window log / token-bucket algorithm implemented with Lua scripts) so all nodes share a single counter per user, enforcing the true global limit.
Local in-memory counters in a multi-node deployment cause each node to track its own quota independently, so the effective global limit becomes limit × node_count. The standard fix is a shared, atomic counter in a fast distributed store like Redis. Redis's INCR + EXPIRE commands provide an atomic fixed-window counter; more sophisticated approaches use a sliding-window log or a token-bucket/leaky-bucket algorithm implemented with Lua scripts to guarantee atomicity and fairness across all nodes.
HTTP & APIs/api-security/rate-limiting
A client exceeds an API's published request quota. Which response should a well-behaved server send, and how should a cooperative client react?#
Options
Show answer
The server should send 429 Too Many Requests, ideally with a Retry-After header, and a cooperative client should back off and wait that long before retrying. 429 is the dedicated status for per-client throttling. 503 signals the whole service is overloaded, 403 is an authorization failure where re-authenticating will not help, and 400 means the request itself is malformed.
429 Too Many Requests is the dedicated status for per-client throttling (RFC 6585), and it SHOULD carry a Retry-After header — a delay in seconds or an HTTP-date — telling the client how long to wait before retrying (RFC 9110 §10.2.3). A cooperative client honours that signal and backs off rather than hammering the endpoint. 503 signals that the whole service is overloaded or down for maintenance (it can also carry Retry-After, but it is not the per-client throttling status). 403 is an authorization failure, where re-authenticating does not help. 400 means the request itself is malformed; being over quota does not make a request malformed. Many APIs also expose the informational RateLimit-Limit / RateLimit-Remaining / RateLimit-Reset headers (IETF draft) so a client can self-pace before it ever hits the 429.
HTTP & APIs/api-security/rate-limiting
A high-traffic public REST API is experiencing abuse from scrapers and is being rate-limited at the gateway. Which of the following strategies are correct and effective approaches to enforce rate limiting in a distributed, multi-instance deployment?#
Options
Pick every one that applies.
Show answer
The correct strategies are: (A) shared Redis INCR with TTL for fixed-window counting, (C) atomic Lua-script token buckets on Redis, and (E) sliding-window logs using Redis sorted sets. All three coordinate state across distributed instances and avoid race conditions. Local in-memory counters with gossip (B) allow over-serving, and IP-only limiting (D) is easily defeated by IP rotation.
Options A, C, and E are correct. A shared Redis instance ensures all gateway nodes see the same counter state. Using INCR with TTL provides a simple fixed-window counter without race conditions. A Lua script on Redis executes atomically, making token bucket check-and-decrement safe. Sliding window logs with sorted sets give high-accuracy limiting. Option B is incorrect because local in-memory counters with lazy gossip allow significant over-serving before corrections propagate. Option D is incorrect as a long-term strategy because IP-based limiting is trivially bypassed by rotating IPs, and shared IPs (NAT, CDN egress) unfairly throttle legitimate users.
HTTP & APIs/api-security/rate-limiting
A Node.js API gateway uses the following sliding-window rate-limiter logic. Given that the current Unix timestamp is 1000 seconds and the client has prior request timestamps of [994, 996, 998, 999] stored in a sorted set, what does the function log when a new request arrives at t = 1000 with a 5-second window and a limit of 4 requests?#
function checkRateLimit(timestamps, now, windowSecs, limit) {
const windowStart = now - windowSecs; // 1000 - 5 = 995
const recent = timestamps.filter(t => t > windowStart);
if (recent.length >= limit) {
const retryAfter = windowSecs - (now - recent[0]);
console.log(`429 Too Many Requests. Retry-After: ${retryAfter}s`);
} else {
recent.push(now);
console.log(`200 OK. Requests in window: ${recent.length}`);
}
}
checkRateLimit([994, 996, 998, 999], 1000, 5, 4);Options
Show answer
200 OK. Requests in window: 4
windowStart = now - windowSecs = 1000 - 5 = 995. The filter t > 995 (strictly greater than) drops 994 (which equals 995 − 1, not strictly greater) and keeps [996, 998, 999] — that is 3 entries. Since 3 < 4 (the limit), the if branch is not taken; the else branch runs, pushes 1000 onto recent making its length 4, and logs 200 OK. Requests in window: 4. Option (b) would be the output only if all four prior timestamps were in-window (i.e., recent.length >= 4 before the push), but that is not the case here because 994 is excluded by the strict > comparison.
HTTP & APIs/api-security/rate-limiting
A high-traffic API gateway implements a token bucket rate limiter. An engineer is auditing the implementation for security and correctness gaps. Which of the following statements about token bucket rate limiting in a distributed, multi-node API gateway are true? Select all that apply.#
Options
Pick every one that applies.
Show answer
The two true statements are A and B. Using INCR + EXPIRE without atomicity in Redis creates a race condition that can allow excess requests (A). A token bucket permits bursts up to its capacity even when the average rate is at the limit, unlike a fixed-window counter (B). The other options are false: IP-only keying fails behind NAT, Retry-After format alone cannot prevent thundering herds, and sliding-window logs are O(n) in memory per client.
A: Without atomicity (a Lua script or WATCH/MULTI/EXEC), multiple nodes can read the same counter value simultaneously before any node increments it, allowing bursts beyond the configured limit — a classic TOCTOU race condition. B: The token bucket explicitly accumulates tokens up to a bucket capacity, which permits bursts up to that capacity; a strict fixed-window counter resets at intervals and does not smooth burst allowance in the same way. C is false — behind a NAT gateway many users share one IP, so IP-only keying both over-limits innocent users and under-limits multi-IP attackers; keying on an authenticated identity or API key is necessary. D is false — neither HTTP-date nor delta-seconds format alone prevents thundering-herd storms; when all clients receive the same Retry-After value they will all retry at approximately the same moment regardless of format. Preventing thundering herds requires client-side randomized jitter or exponential backoff; in fact, a shared absolute timestamp can worsen retry synchronization when clients have synchronized clocks. E is false — a sliding-window log stores a timestamped entry for every request inside the window, so memory is O(requests-per-window) per client, which is worse than the O(1) fixed-window counter.
HTTP & APIs/api-security/rate-limiting
An API uses JWT bearer tokens for authentication and enforces rate limiting per API key at the gateway layer. An attacker with one valid API key wants to bypass the rate limit without obtaining additional keys. Describe two distinct, technically specific bypass techniques the attacker could attempt, and for each technique explain the exact countermeasure an API team should implement to prevent it.#
Show answer
Technique 1 — Header spoofing / key extraction from forwarded headers: The gateway may trust and rate-limit on a client-supplied header such as X-Forwarded-For or a custom header rather than validating the signed JWT. An attacker can forge these headers to cycle through fake identities while reusing one real API key. Countermeasure: always derive the rate-limit key from the cryptographically verified JWT sub or jti claim (or the authenticated API key after signature validation), never from untrusted request headers alone.
Technique 2 — Distributed request spreading across gateway shards (no shared state): If the rate limiter stores counters locally per gateway node without a shared backend (e.g., Redis), an attacker routes requests across multiple nodes. Each node sees a fraction of the total traffic and never trips the per-key limit. Countermeasure: use a centralized, atomic counter store (e.g., Redis with Lua-script-based atomic increment) or a gossip/sync protocol so all gateway nodes share a single view of each key's consumption window.
Both bypass classes are real and frequently exploited: (1) header injection tricks the gateway into rate-limiting on an attacker-controlled identity rather than the verified credential — fixed by anchoring rate-limit keys to validated JWT claims; (2) distributed gateway deployments with node-local counters are trivially bypassed by spreading traffic, fixed by a shared atomic store. Strong answers name specific headers/claims and implementation primitives (Lua scripts, Redis, MULTI/EXEC).
Sources
The official documentation these questions are checked against:
Related interview questions
Job market
See http-apis salaries and hiring demand from live job postings.
Practise these until they stick
That's every question we hold on this topic, and the page marks what you pick. What it can't do is remember. A free account keeps every answer, and what you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan