URL Shortener System Design Without the Cliches
Related service: Mock interviews
A URL shortener system design interview does not score the base62 answer. Every candidate has it.
The round scores the 4 numbers you ask first, and the ID scheme you pick.
Whether you spot the custom alias race unprompted. Whether you can say why 302 rather than 301.
On this page
The question is asked because everyone has read the answer. That is the point.
“Base62 encode an auto-increment ID, cache reads in Redis” stops carrying signal. The interviewer scores what you do around it.
The 4 numbers that decide a URL shortener system design
| Question | Why it changes the design |
|---|---|
| Writes per second? | 100 per second is 1 database. 100,000 needs sharding from day 1 |
| Read to write ratio? | 100:1 means read replicas and cache. 2:1 means neither is worth it |
| How long do links live? | Forever means no deletion path and unbounded growth. 30 days changes the storage model completely |
| Custom aliases allowed? | This is the single biggest fork in the question |
Do the arithmetic out loud next. 1,000 writes a second at 500 bytes a row: 43 GB a day. 16 TB a year.
The arithmetic decides whether 1 database is even an option.
The fuller list is in 6 questions to ask before you design anything.
Where does the ID come from?
Base62 over a counter is correct and takes 20 seconds. The hard part is where the counter comes from.
A single auto-increment column. Fine at 100 writes a second, a bottleneck at 10,000. Say the threshold, not just the objection.
Random 7 characters with a uniqueness check.
62 to the power of 7 is 3.5 trillion. At a billion links stored, a collision is 1 in 3,500.
Pre-allocated ranges.
Each server takes a block of a million IDs. No per-write coordination. Gaps when a server dies, which nobody cares about.
Snowflake-style IDs. Timestamp plus machine plus sequence. Long strings, which defeats the purpose unless you rebase them.
Pick for the numbers you were given. At 100 writes a second the auto-increment column is right.
Pre-allocated ranges there is over-engineering, which is its own scored failure.
Why do custom aliases change everything?
Generated and custom keys now share a namespace. 2 users can claim the same alias in the same millisecond.
The fix is a uniqueness constraint in storage and an insert that can fail.
A read-then-write check in application code is exactly the race you were trying to close.
Candidates who say “check if it exists, then insert” get 1 follow-up.
“2 requests hit different servers at the same millisecond. Walk me through it.” Many do not recover.
State the constraint up front and you never enter that hole.
The read path is the whole system
At 100 reads per write, this is a read system with a write feature attached.
A redirect is 1 lookup and 1 response in single-digit milliseconds. It should almost never touch the database.
Cache, with a stated policy. LRU over the hot keys. Link traffic is heavily skewed. Do not quote a hit rate you cannot support.
Say what happens on a miss. Read through, populate, return. Then say what happens when the database is also down.
A stale cache serving a redirect beats a 500. Being willing to say that is a senior signal.
Put the redirect at the edge. The lookup table is small and almost never changes per key. The hot set fits close to the user.
What do candidates forget in a URL shortener system design?
Deletion and expiry. Partition by expiry date and drop whole partitions. A row sweep over 16 TB is its own design problem.
Abuse. A shortener is a phishing tool with a nice API.
Safe-browsing check on write, rate limit per account, a kill switch for any key. The kill switch is why you chose 302.
Analytics. Emit an event, aggregate offline, accept a few seconds of lag.
The custom domain feature.
Custom domains turn the key from a string into a pair. Design the schema without it and migrating 16 TB is your next 2 quarters.
What does the scorecard say?
None of the scorecard lines for this round are about base62.
Strong: “Asked for read/write ratio and link lifetime before designing. Chose the simpler ID scheme and named where it breaks.”
Weak: “Correct architecture from memory. Could not justify 302 over 301. At 100x load, added servers, named no bottleneck.”
The second candidate knew more of the answer. The first one got the offer.
Common questions
Should a URL shortener return 301 or 302?
302 for almost every real shortener. A 301 is cached by the browser more or less forever. That makes the second click free. It also makes your analytics blind and your kill switch useless. You need to disable abusive links everywhere at once. 302 keeps that possible.
How do you handle link expiry at scale?
Partition by expiry date and drop whole partitions, rather than deleting rows. A row-by-row sweep over 16 TB is a design problem of its own. It competes with your read path for the same resources. If links live forever, say so and account for unbounded growth in the storage number.
Is random key generation ever better than a counter?
When you need unguessable keys. You pay a read before every write to check for collisions. 62 to the power of 7 is about 3.5 trillion. Collisions are rare at a billion links. The check is still on the write path. Name that cost rather than skipping it.
Should click analytics be exact?
Almost never, and say why. Counting clicks synchronously puts a write on the hottest path in the system. Emit an event, aggregate offline, and accept that the number lags by seconds. If the interviewer insists it must be exact and live, that is a different system. And a much more expensive one.
How does a URL shortener work?
A short code maps to a long URL in a key-value store. A write generates the code and stores the pair. A read looks the code up and redirects. Reads usually far outnumber writes; 100 to 1 is a common assumption. That ratio, not the encoding, is what the design has to answer.
The short version
The design is known, so it is not what is being scored.
Get 4 numbers and do the arithmetic out loud. Pick the simplest ID scheme the numbers allow, then name where it stops working.
Spend your time on the read path, the alias race, and the 302.
The rest of the format is in the system design interview playbook.
ArchitectPath builds the underlying knowledge, 133 steps from an empty machine to a multi-cloud system.
To have this question run at you, book a system design mock interview.