Design a URL Shortener
Practice designing a URL shortener with short-code generation, redirect latency, link lifecycle, abuse controls, analytics isolation, and scaling tradeoffs.
What you'll learn
Run the architecture drill
- How to scope a redirect service before jumping to a global architecture.
- Tradeoffs between generated codes, custom aliases, caching, and storage.
- How to separate the latency-critical redirect path from analytics and abuse workflows.
A URL shortener looks small because its primary request is a redirect. The real design work is making that redirect fast and reliable while handling code generation, custom aliases, expiry, abuse, analytics, and a read-to-write ratio that can be wildly uneven.
Start with the architecture drill, then follow the request path through scale, failure, and a defensible interview answer.
Make your assumptions and decision path easy to inspect.
ATOFF architecture reasoning canvas
Design a URL Shortener: the architecture drill
Short answer
A URL shortener should make redirects fast and durable while isolating slower concerns such as analytics, custom aliases, expiry, and abuse review.
10× evolution
Cache hot redirects aggressively while preserving one durable canonical mapping.
01 Decision checkpoint
Design brief
Resolve a code through cache and durable mapping storage, return the redirect quickly, and keep optional analytics off the user-visible critical path.
02 Decision checkpoint
First request path
Generate collision-resistant identifiers or reserve custom aliases atomically so one code always maps to one intended destination.
03 Decision checkpoint
Failure drill
Apply reputation checks, quotas, and takedown state without making every healthy redirect wait on a slow moderation dependency.
Say it in the interview
I would optimize the read-heavy redirect path first, then explain code uniqueness, cache invalidation, and asynchronous analytics.
- 1
Link creator
create or update: Link API code + lifecycle
- 2
Link API code + lifecycle
persist mapping: Authoritative link store
- 3
Authoritative link store
- 4
Browser
short code: Redirect edge + mapping cache
- 5
Redirect edge + mapping cache
cache miss: Authoritative link store · emit click: Click analytics stream
- 6
Click analytics stream
- Link creator flows to Link API code + lifecycle via create or update.
- Link API code + lifecycle flows to Authoritative link store via persist mapping.
- Browser flows to Redirect edge + mapping cache via short code.
- Redirect edge + mapping cache flows to Authoritative link store via cache miss.
- Redirect edge + mapping cache flows to Click analytics stream via emit click.
Walk the design under pressure
Clarify what a link means before designing it
Start with create, redirect, custom alias, expiration, disable, and analytics requirements. Ask whether redirects must be global, whether aliases are case-sensitive, whether a deleted link should ever be reused, and what abuse or phishing controls are in scope. These answers define the data model more than a guessed request rate does.
For a first version, one link record can hold the short code, destination, creator, lifecycle state, and expiration. Redirect behavior should make disabled or expired states explicit instead of silently treating them as missing records.
Pick code generation that fits collision and ownership rules
A monotonically allocated ID encoded into a compact alphabet is easy to reason about but can reveal volume and needs coordination. Random codes avoid predictability but require collision handling. Preallocated ranges can reduce coordination, while custom aliases need a separate uniqueness and moderation path.
The redirect mapping is read-heavy and keyed by the code, which makes a key-value-oriented access path natural. The authoritative store remains important for cache misses, expiration checks, and lifecycle changes; the cache is an optimization, not the truth.
Keep redirects fast by isolating secondary work
The redirect path should validate the code, find the current mapping, and return the correct redirect response with minimal synchronous dependencies. Cache hot mappings close to traffic, bound storage lookups, and define what happens if analytics is unavailable—usually the redirect still succeeds while tracking is delayed or sampled.
A click event can be emitted asynchronously with the link ID, coarse request metadata, and correlation information. Analytics consumers can aggregate it later without turning a user redirect into a fanout of database writes.
Where the simple architecture breaks
A viral link creates a hot key that can overload one cache node or origin. A malicious user can create unsafe destinations or attempt aliases that look trusted. Regional caches can serve an old mapping briefly after a disable request. Each problem has a different response: hot-key replication, risk review, short invalidation windows, and a stricter source-of-truth check for high-risk state changes.
In an interview, explain the redirect consistency rule and name the failure behavior. At staff level, add abuse operations, global cache propagation, analytics privacy boundaries, and a safe migration strategy for changing code generation without breaking existing links.
Keep this with you
Key takeaways
- Design the redirect path separately from creation, analytics, and moderation work.
- Short-code generation is a lifecycle and collision decision, not just an encoding trick.
- Hot links, disabled links, and abuse are the real scaling and correctness tests.
Practice aloud
Interview questions to explore
- 1.Would you use sequential IDs, random codes, or both—and how do collisions work?
- 2.What happens if a popular short code becomes a hot key?
- 3.How quickly must a disabled link stop redirecting globally?
Common follow-ups
Frequently asked questions
Why cache URL mappings?
Redirects are often far more frequent than link creation. A cache can serve repeated code-to-destination lookups with low latency while the authoritative store remains available for misses and lifecycle changes.
Should click analytics be synchronous?
Usually not. The user needs a correct redirect, while analytics can normally be recorded asynchronously with bounded loss or later reconciliation rules.
Already an Elite member? Open the complete walkthrough.
Need the broader preparation context? Go back to Interview Preparation for behavioral readiness, question practice, and the larger AceTheOffer preparation framework.