01
URL Shortener
Shorten a long URL. Read-heavy. Don't collide.SavedSaved on this device — Saved on this device
01Clarifications
What would you ask before drawing a single box?
Ambiguity you would resolve with the interviewer: scope, scale, who uses it, what counts as done.
AI staff engineer
Enter to send · Shift+Enter for a new line
About URL Shortener
Shorten a long URL. Read-heavy. Don't collide.
- Difficulty
- beginner
- Time
- about 25 minutes
- Stages
- 10
- Topic
- System Design Fundamentals
How this problem is worked
Ten stages, from the questions you would ask an interviewer to the trade-offs you would defend. Each asks one question, and the simulator runs the architecture you draw against the requirements you wrote.
- 01ClarificationsWhat would you ask before drawing a single box?
- 02Functional reqsWhat must this system actually do?
- 03Non-functionalWhat must it promise about speed, uptime and correctness?
- 04Capacity estimationHow much load and data does this have to hold?
- 05API designWhat does the outside world call, and what comes back?
- 06Data modelWhat gets stored, and what is it looked up by?
- 07Use-case breakdownHow does each requirement actually get served?
- 08High-level designWhich components handle a request, and in what order?
- 09Deep divesWhich part breaks first, and what do you do about it?
- 10Trade-offsWhat did this design cost, and what breaks at 10×?
Primary sources for this problem
- Flickr Ticket Servers
- Twitter Snowflake
Build the primitives this design leans on
Each one is an animated curriculum that constructs the system from scratch.
- Build Build RedisAn in-memory data-structure server: one thread, rich types, optional persistence, async replication. Internalize the cost of single-threaded simplicity and a dozen caching/HA decisions get easier.
- Build Build a Bitcask-style KV storeThe simplest possible KV store that still works: an append-only log on disk + an in-memory hash index. Build it from first principles and feel which trade-offs every later store inherits.
- Build Build a CDNA globally-distributed reverse proxy whose only job is to (a) terminate the user's TCP/TLS milliseconds away and (b) serve a cached origin response so origin never sees the request. Internalize edge caching, anycast, TTL, revalidation, SWR, purge, the Vary footgun, origin shield, bypass, and hit ratio — and the dozen ways to misconfigure each.
More in System Design Fundamentals
The four primitives every later problem assumes — unique IDs, rate limits, caching a read-heavy endpoint, and making a retry safe.
- PastebinStore text/code blobs with TTL and access control.
- Distributed Unique ID GeneratorGenerate globally unique, monotonic-ish IDs at scale.
- Distributed Rate LimiterEnforce a per-key request limit across a fleet of enforcers — accurately, in under a millisecond, without becoming the outage.
- Submit Order (Prevent Double-Charge)Idempotency keys, dedup window, retry storms.
Browse the full problem catalog, or see what the simulator does and does not model.