A rate limiter that works on one server and breaks across ten is a common interview trap. This is the implementation-level walkthrough: Redis Lua scripts to close race conditions, what actually happens across regions, and where client-side limiting still earns its keep.
Rate limiter questions look simple and punish candidates who treat them that way. This guide covers the four algorithms interviewers expect you to know — token bucket, sliding window, fixed window counter — and how to build a distributed, Redis-backed version that survives a real follow-up.
A layer-by-layer breakdown of how a request actually moves through a URL shortener — CDN, load balancer, app servers, cache, and database — with separate diagrams for the write path and the read path.
Back-of-the-envelope math for a URL shortener — QPS, storage growth over five years, bandwidth, and cache sizing using the 80/20 rule. The exact numbers interviewers expect you to produce on a whiteboard.
The schema, REST API contracts, rate limiting strategy, and SQL-vs-NoSQL decision for a URL shortener — the implementation details interviewers probe once the high-level architecture is settled.
Everyone can design a URL shortener that works for 10 requests a second. Here's what actually breaks when you hit 10,000 requests a second: database hotspots, cache stampedes, hash collisions, and the geographic latency problem nobody mentions in the whiteboard round.