You run a SaaS API. POST /v1/messages is the money endpoint.
Plan limit: 100 requests/minute per API key. Customers keep getting 429s at minute boundaries even though their average RPS is well under the cap.
Here’s what’s happening in prod:
• 12:59:58 → customer sends 90 requests (batched job kicked off)
• 13:00:02 → same customer sends 90 more (next tick)
• Your counter resets at 13:00:00
• Both bursts pass. 180 requests in 4 seconds. Your downstream database starts crying.
Now Support is on your back about 429s, and SRE is on your back about traffic spikes. You need to replace the limiter this week.
FOUR OPTIONS ON THE TABLE:
A) Fixed Window — bucket per (api_key, minute). Increment, check, reject. Simple, fast, one Redis key per user.
B) Sliding Window Log — store every request timestamp in Redis. Count requests in the last 60s on every call. Exact to the millisecond.
C) Token Bucket — 100 tokens per key, refill at 100/60 per second. Each request takes a token. Bursts up to 100, then shaped.
D) Leaky Bucket — queue incoming requests, dispatch at a constant 1.66/sec. Excess requests wait or get dropped.
All four ship in production somewhere. Three of them are the wrong pick for this specific situation. One of them is what AWS, Stripe, and GitHub actually run.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments (including which answer is the senior-engineer trap).
If your team has ever argued about rate limiting in a design review, share this with them. The disagreement is where the learning happens.
Drop your answer 👇
#30DaysOfSystemDesign #SystemDesign #DistributedSystems #SoftwareArchitecture

You can share you thought with this squad 

Backend Developer 

A practical system design challenge about rate limiting for a SaaS API. The scenario presents a classic fixed-window boundary problem where customers experience 429 errors despite staying under average limits, because burst traffic straddles minute boundaries. Four rate limiting strategies are compared: Fixed Window, Sliding Window Log, Token Bucket, and Leaky Bucket. Readers are asked to identify which algorithm AWS, Stripe, and GitHub actually use and why the others are wrong for this specific situation.

3/30 Days System Design Questions!

I would go for B. Seems to fit best into requirements.