URL Shortener
easyOpen designVery commonly asked~45 minPhone screenHLD roundSDE-2 and upAmazonGoogleMicrosoftFlipkartAtlassianStorage & Data ModellingCachingSharding & Partitioning
The question, as asked
“Design a URL shortener — something like TinyURL or bit.ly.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Scale, in writes per day. 'A lot' is not a number — ask for one, or state your own assumption out loud and get it confirmed. Every later decision hangs off it.
- Read-to-write ratio. Shorteners are overwhelmingly read-heavy (100:1 is the usual working figure), and that single ratio is what justifies the entire cache layer.
- Custom aliases? If users can ask for /my-campaign, you need a uniqueness check and a reserved-word list, and you can no longer derive the key purely from the URL.
- Do links expire, and can they be edited or revoked after creation? This quietly decides your redirect status code, which is the question they will come back to.
- Analytics — click counts, geography, referrer? Analytics is usually the actual product, and it dictates that every click must reach your servers.
- Latency target. A redirect sits in front of someone else's page load, so the budget is tens of milliseconds, not hundreds.
- Retention. Forever, or N years? This is the difference between tens of terabytes and hundreds, and it decides whether you ever reclaim keys.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.