Interview questions

Interview questions (with the counter-questions you'll get)

Q1. Design a rate limiter.

They're testing: the classic question, end to end.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Clarify who is limited (per key, user, IP), the limits and whether bursts are allowed. Use a token bucket per client, with tokens and last-refill time stored in Redis and updated atomically by a Lua script. Enforce it in the API gateway, return 429 with Retry-After and RateLimit headers, shard Redis by key, and decide fail-open or fail-closed. Add per-IP limits at the edge and per-action limits in services.
3
4**Counter-questions:**
5- *"What if Redis adds too much latency?"* → Keep it in the same zone, use local token batches synced periodically, or a local backstop limit.
6
7**Trap:** describing an algorithm without saying where state lives in a multi-server setup.

Q2. Compare token bucket, leaky bucket, fixed window, sliding log and sliding window counter.

They're testing: algorithm knowledge.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Token bucket allows bursts up to capacity, then a steady rate, with two numbers of state. Leaky bucket queues and outputs at a fixed rate, smoothing traffic with added delay. Fixed window is a simple counter but allows double the limit at boundaries. Sliding log is exact but stores every timestamp. Sliding window counter weights the previous window's count to approximate a sliding window with two counters.
3
4**Counter-questions:**
5- *"Which would you pick?"* → Token bucket by default; sliding window counter for high-volume accuracy; sliding log for small exact security limits.
6
7**Trap:** not knowing the fixed window's boundary problem.

Q3. How do you rate limit across many servers?

They're testing: distributed state.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Keep the counter in a shared store like Redis and update it atomically (INCR, or a Lua script for token buckets), keyed by client and window with an expiry. Local per-server limits are inaccurate under uneven load. A hybrid syncs local counts or takes tokens in batches to reduce Redis calls.
3
4**Counter-questions:**
5- *"What's wrong with GET then SET?"* → Concurrent requests read the same count and all pass; it's a lost-update race.
6
7**Trap:** per-server limits presented as exact.

Q4. Fail open or fail closed when the rate limiter's store is down?

They're testing: judgement under failure.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** It depends on what the limit protects. For general API fairness, fail open with a local backstop limit, since rejecting all traffic is an outage. For security limits like login or OTP attempts, fail closed or fall back to a strict local limit, since the cost of letting attacks through is high.
3
4**Counter-questions:**
5- *"How do you know it's down?"* → Timeouts on limiter calls with a short budget, plus a circuit breaker (Chapter 29).
6
7**Trap:** one answer for every limit.

Q5. What should the API return when a client is rate limited?

They're testing: client experience.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** 429 Too Many Requests, a Retry-After header, limit/remaining/reset headers (on all responses so clients can pace themselves), and a clear error body naming the limit and plan. Clients should back off with jitter and respect Retry-After.
3
4**Counter-questions:**
5- *"429 or 503?"* → 429 for "you're over your limit", 503 for "we're overloaded".
6
7**Trap:** returning 500 or silently dropping requests.

Q6. How do you stop credential stuffing?

They're testing: security thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Limit per target account (and per IP + account), not only per IP, since attacks spread across thousands of IPs. Add progressive delays and CAPTCHAs, check passwords against known breached lists, encourage two-factor authentication, and use bot detection at the edge. Avoid hard lockouts that let attackers lock out real users.
3
4**Counter-questions:**
5- *"Why not lock the account after 5 failures?"* → Attackers can then lock out any user on purpose; prefer delays and step-up verification.
6
7**Trap:** "per-IP rate limiting solves it".

Q7. How would you rate limit by cost rather than by request count?

They're testing: nuance.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Give each endpoint or operation a cost (a search costs 5, a simple read costs 1, an export costs 50) and take that many tokens from a token bucket. For GraphQL, compute a query cost from its fields and depth before running it.
3
4**Counter-questions:**
5- *"What if the cost is only known afterwards?"* → Charge an estimate up front and adjust after, or limit concurrency instead of rate.
6
7**Trap:** treating every request as equal when some are 100× more expensive.

Q8. Where would you put rate limiting in an architecture?

They're testing: layering.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Per-IP and flood limits at the edge (CDN or WAF), per-key and per-plan limits at the API gateway, business limits (logins, OTPs, reviews) inside services, and outbound limits in front of partners with strict quotas. Each layer uses the information it has.
3
4**Counter-questions:**
5- *"Doesn't that duplicate logic?"* → Each layer has a different key and purpose; share the library and config, not the limit.
6
7**Trap:** one limiter for everything at one layer.

Q9. How do you handle limits for clients behind one shared IP?

They're testing: real-world awareness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Many users share an IP behind mobile carriers, offices and VPNs, so per-IP limits must be generous and used for floods, not fairness. Use authenticated keys (user, account, API key) for fair-use limits, and combine IP with other signals for abuse.
3
4**Counter-questions:**
5- *"And IPv6?"* → One user can have many addresses, so limits often key on a prefix (like /64) rather than the full address.
6
7**Trap:** strict per-IP limits that block an entire office.

Q10. Design a rate limiter as a service used by many teams.

They're testing: scaling the idea (Chapter 32 covers it fully).

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A central service or library with rules configured per team (key pattern, algorithm, limit, window), backed by a sharded Redis cluster with atomic scripts. Calls are made from gateways or sidecars with a tight timeout and a fail-open default, rules are cached locally and updated without deploys, and there are dashboards for limited requests per rule.
3
4**Counter-questions:**
5- *"How do you avoid a network hop per request?"* → A library or sidecar with local token batches, syncing with the central store.
6
7**Trap:** a single Redis instance for the whole company.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 25.1 Why limit | Level 5.1, Q1 |
18| 25.2.1 Token bucket | Level 1A.1, Level 2.1, Level 3.1, Q2, Q7 |
19| 25.2.2 Leaky bucket | Level 1A.2, Level 3.2, Q2 |
20| 25.2.3 Fixed window | Level 1A.4, Level 2.2, Level 3.3, Level 4, Q2 |
21| 25.2.4 Sliding log | Level 1A.3, Level 2.3, Level 3.3, Q2 |
22| 25.2.5 Sliding window counter | Level 1A.5, Level 2.3, Level 3.3, Q2 |
23| 25.3 Comparing | Level 1A, Q2 |
24| 25.4 Distributed with Redis | Level 2.4, Level 2.5, Level 3.4, Level 4, Level 5.3, Q3, Q4 |
25| 25.5 Where to limit | Level 5.2, Q8 |
26| 25.6 429 and headers | Level 3.5, Level 5.4, Q5 |
27| 25.7 Bots and abuse | Level 1B, Level 2.6, Level 5.5, Q6, Q9 |
28
29---

25. Rate Limiting