Functional
- Create a short alias for a validated HTTP(S) URL, with optional custom alias and expiry.
- Resolve an alias to its current destination and return an HTTP redirect.
- Disable abusive links and collect click events without delaying redirects.
End-to-end walkthrough
URL Shortener
Resolve compact links with low latency while creating globally unique aliases.
Frame before solving
Requirements & boundaries
Quality attributes
- Redirect p99 under 50 ms from the nearest region.
- Redirects remain available during a regional failure; newly created aliases must never collide.
- Read-after-create should work immediately for the creator.
Explicitly out of scope
- Full marketing attribution and audience analytics.
- Crawling or archiving destination content.
Size the important constraints
Back-of-the-envelope estimates
Design for a 10× peak and cache the read path.
The write path can favor correctness over extreme throughput.
Partition by alias and apply lifecycle policies.
Random allocation makes collision probability operationally negligible with checks.
These are reference assumptions, not universal facts. In an interview or architecture review, change them when the product context changes.
Define the contract
API & data model
Core operations
/v1/linksCreate an alias; accept Idempotency-Key and optional expiry./{alias}Return 301/302 redirect without waiting for analytics./v1/links/{alias}Disable an owned alias and invalidate caches.Authoritative records
alias PK, destination, owner_id, created_at, expires_at, statusAlias is the partition key; destination is validated and normalized once.alias, occurred_at, coarse_region, referrer_classAppend asynchronously; never join this store on the redirect path.Trace the critical path
Architecture & request flow
- 1Validate long URL→
- 2Generate or reserve alias→
- 3Persist alias mapping→
- 4Cache popular aliases→
- 5Redirect at the edge
Redirect API
Resolve aliases and return redirects
Alias service
Create collision-safe short codes
Mapping store
Durably store alias-to-URL records
Edge cache
Serve hot redirects close to users
Reason about the hard parts
Critical design deep dives
Alias generation
Generate 128 bits of randomness, encode the first 8–10 Base62 characters, and use conditional insert. Retry only on collision. Custom aliases use the same uniqueness boundary but stricter reservation and abuse checks.
Cache correctness
Cache positive mappings for hours and disabled/unknown aliases briefly. Publish invalidations on delete or destination change. During invalidation lag, a short TTL bounds exposure; high-risk disable operations can consult a denylist at the edge.
Regional writes
Allocate aliases in the accepting region with a globally unique conditional write or region-prefixed ID. Replicate mappings outward, then acknowledge only after the local read path can resolve the alias.
Make trade-offs explicit
Architecture decisions
ChoiceWhyCost
Random IDsAvoid a central sequence bottleneckRequires collision checks or enough entropy
Cache asideMakes the dominant read path fastInvalidation and abuse controls become explicit
Failure-first review
What happens if…?
Cache fleet fails
Fall back to the mapping store, cap concurrency, and shed nonessential analytics.
Alias creation is retried
Use an idempotency key so one request cannot create multiple aliases.
Avoid premature complexity
How the design evolves
Single region
API + replicated KV store + cache-aside
Move here when: Launch and validate the product.
Read scale
CDN/edge redirect worker and partitioned cache
Move here when: Origin traffic or global latency becomes material.
Global writes
Multi-region alias allocation, abuse denylist, async analytics log
Move here when: Regional continuity and local creation are required.
Test the reasoning
Interview follow-ups
Would you use 301 or 302 redirects?
Strong answer signal: Discuss browser/CDN caching, destination mutability, and analytics visibility.
How do you stop one viral alias from overloading a shard?
Strong answer signal: Move resolution to edge caches; partition click events independently.
A create call times out. How does the client learn whether it succeeded?
Strong answer signal: Use an idempotency key and a retrievable operation result.
Build from primitives