URL Shortener Service – System Design Interview Preparation

Practice designing a URL shortening service like bit.ly. Cover short URL generation, redirection, and analytics.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the URL Shortener design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing URL Shortener is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Generating a short, unique, non-guessable key at write time without a coordination bottleneck - and deciding whether redirects are a cache read or a database read.

Scale to establish before drawing anything

100M new URLs a month, roughly 40 writes a second; reads at 100:1, so about 4,000 redirects a second.
A 7-character base62 key gives 3.5 trillion combinations - enough for decades at that write rate.
500 bytes per record, so 100M a month is about 50 GB a year, and all of it is hot for roughly a week.

Core components

Key generation service – Pre-generates keys in blocks, or hashes the long URL and resolves collisions. Not an auto-increment that every writer contends on.
Key-value store – Short key to long URL. The access pattern is a point lookup, which is why this is not a relational schema.
Redirect service – Stateless, cache-first, returning 301 or 302 - and that choice decides whether you can count clicks.
Cache – The top 20% of keys serve most traffic. LRU with the week-old working set in memory.
Analytics pipeline – Click events written asynchronously, never in the redirect path.

Trade-offs to defend

301 versus 302 – 301 is cached by the browser, which removes load and destroys your click counts. 302 keeps every redirect coming back to you. Most candidates say 301 without noticing the second half.
Hash versus counter – Hashing is stateless but needs collision handling; a counter is collision-free but needs a distributed allocator. Say which and why.
Custom aliases – They force a uniqueness check on write, which is the one place this system needs strong consistency.

Follow-up questions to expect

Two users request the same custom alias simultaneously. What stops both succeeding?
A URL goes viral and one key takes 50,000 reads a second. What in your design absorbs that?
Add expiry. How do you reclaim keys without breaking links that are still live?