Design a URL shortener that we would actually run in production. Assume it is used inside marketing emails, so redirects have to be fast and links can never break.
What they are really testing: This looks like a toy question but it is really about read heavy design, key generation under concurrency, and whether you understand that a broken link is a permanent data loss event.
A real interview question
Design a URL shortener that we would actually run in production. Assume it is used inside marketing emails, so redirects have to be fast and links can never break.
What most people say
drag me
“I would hash the long URL with MD5, take the first seven characters, store it in a database, and redirect. Maybe put Redis in front of it.”
It skips the read to write ratio entirely, ignores hash collisions and hot keys, and never says what happens when the cache is cold or the database is down, which is exactly the moment links break.
The follow-ups they ask next
One link in a viral campaign is taking 40 percent of your traffic. What breaks?
Talk about the hot partition, and how an edge cache with an immutable mapping absorbs it while the origin sees almost nothing.
How do you count clicks without slowing the redirect?
Fire the redirect first, emit the click event asynchronously to a stream, and accept eventually consistent analytics rather than a synchronous write.
What the interviewer is listening for
- Explicitly computes the read to write ratio and designs for reads
- Prefers counter based code generation over hashing and explains collisions
- Treats a lost mapping row as permanent customer facing damage with a near zero RPO
- Separates the redirect path from the analytics path
What sinks the answer
- Uses a relational primary key auto increment exposed directly with no thought on guessability
- Never mentions caching in a system with a 100,000 to 1 read to write ratio
- Writes an analytics row synchronously in the redirect path
- Cannot say what happens to existing links if the database is restored from backup
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I have not shipped a shortener, but the shape I would reason from is this. It is a read heavy system, so I would ask for redirects per second first, then design the read path and the cache, then protect the mapping data as if losing it is unrecoverable.”
Keep going with system design
Mid
Design a log and metrics ingestion pipeline for a platform with about 200 services. Engineers need to search logs and alert on metrics.
Mid
Design an image upload and processing service for a marketplace app. Users upload photos from their phone, and we need thumbnails and a moderation check before the listing goes live. Walk me through it.
Senior
Design an event-driven order processing system for an e-commerce site. Payment, inventory, and shipping are separate services.
Senior
Design an analytics pipeline that produces a daily report for the leadership team by 8am. The data comes from a production database and a stream of app events.
Senior
Design a system that must never lose a message. It ingests payment notifications from a partner and each one must be processed exactly once.
Senior
We have about 50 product teams and every one of them has rolled their own pipeline. Design a CI/CD platform that all 50 can use. Take me through it.
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free