01
Client
The person’s browser or mobile app.
Starts the request and follows the redirect.WorkspacePlayground
Each mode starts with a clear purpose.
LEARN · URL SHORTENER ARCHITECTURE
Understand the complete URL shortener system.
Learn why each component exists, how requests and data move through the architecture, where bottlenecks and failures appear, and how design choices change behavior at scale.
BY THE END, YOU CANTurn product requirements into an architectureExplain the responsibility of every componentTrace create, read and failure workflowsTranslate a user story into HTTP and data operationsFind bottlenecks using demand, capacity and queuesEvaluate caching, resilience and scaling tradeoffs
SYSTEM DESIGN INTERVIEW CHALLENGE
45–60 MINUTESDesign a production URL shortener.
Attempt the prompt before studying the reference architecture. Return after the lecture and compare your decisions with the model.
PROBLEM STATEMENT
Users submit long URLs and receive short links. Opening a short link must quickly redirect to the original destination. Links may expire, and a popular link can receive a sudden traffic spike.
Design the APIs, data model, short-code generation, storage, caching, traffic routing, scaling strategy and failure behavior.NEW LINKS10M / month
REDIRECTS500M / day
PEAK TRAFFIC10× average
LATENCY TARGET< 100 ms
AVAILABILITYHigh for reads
RETENTION5 years
YOUR INTERVIEW PLAN
- 01Clarify functional and non-functional requirements
- 02Estimate read, write, storage and peak traffic
- 03Define create-link and redirect APIs
- 04Choose a data model and short-code strategy
- 05Draw the high-level architecture and request flows
- 06Explain caching, scaling and failure behavior
- 07State important tradeoffs and future improvements
State assumptions when information is missing. Interviewers care about reasoning and tradeoffs more than one perfect architecture.
01
ARCHITECTURE IN PLAIN ENGLISH
Meet the five parts of the system.
Before looking at protocols or capacity, understand the simple job each component performs.
02
Load balancer
The traffic coordinator at the front door.
Chooses a healthy API server for each request.03
API service
The decision maker.
Validates the code, checks storage and builds the response.04
Redis cache
The system’s fast, short-term memory.
Keeps popular mappings close so they can be returned quickly.05
PostgreSQL
The permanent record book.
Stores every durable short-code mapping and its expiry.ONE HEALTHY REQUEST · CACHE HIT
A user opens a popular short link.
Imagine that a7K2 has already been opened before, so its destination is available in the system’s fast memory.
- 1
The user clicks the link. Their browser asks the URL shortener to open
short.example/a7K2. - 2
Traffic reaches the front door. The load balancer sends the request to an available API server.
- 3
The API looks for the code. It asks Redis whether it remembers where
a7K2should go. - 4
Redis remembers it. The saved destination is returned immediately, so the permanent database is not needed.
- 5
The API sends directions back. It tells the browser to redirect to the long destination.
- 6
The browser follows the redirect. The destination page opens, completing the healthy request.
What made it healthy? Every component was available, the mapping was cached, no queue accumulated, and the database was protected from unnecessary work.
02
THE SAME REQUEST · TECHNICAL VIEW
Translate the story into system operations.
The user experience above becomes a sequence of network, application and cache operations.
- 01
GET /a7K2The browser sends an HTTPS read request containing the short code.
- 02
LB → API replica 02The load balancer selects a healthy stateless API instance.
- 03
GET link:a7K2The API validates the code and performs a Redis lookup.
- 04
Cache hit → destination URLRedis returns the mapping, so PostgreSQL is not queried.
- 05
302 Location: https://example.com/guideThe API sends an HTTP redirect with the destination header.
- 06
Browser → destination websiteThe client follows the redirect; that external request is outside the shortener.
Expected resultFast redirect · zero database operations · no pending work
Key design ideaCache-aside keeps PostgreSQL authoritative while Redis accelerates popular reads.
03
INTERACTIVE ARCHITECTURE
Follow the request through the real diagram.
Choose a workflow, advance one step at a time, and connect each explanation to the highlighted component.
LIVE ARCHITECTUREClick a component in this workflow
WORKFLOW OPEN · CACHE HIT
Active now: client · The highlighted route is the path this request follows.
Open a short link
The browser requests GET /a7K2. The code identifies a saved destination.
- Data moving
GET /a7K2 plus normal browser headers- What this component does
- The browser asks the shortener to resolve the code a7K2.
- Why it matters
- Opening is a read. Creating a new mapping is a write.
- What could go wrong
- The network can be unavailable, or the code can be malformed.
04
COMPLETE SCENARIO CATALOG
Every scenario covered in this URL shortener lab.
Normal request paths explain how the product works. Traffic, failure and resilience scenarios explain how the architecture behaves when conditions change.
Core request paths
4 workflows01Normal
Open · cache hit
A popular short code is already stored in Redis.
Client → Load balancer → API → Redis → API → ClientRedis returns the destination and PostgreSQL does no work. This is the fastest normal read path.02Normal
Open · cache miss
The short code is valid but Redis does not currently hold it.
Client → Load balancer → API → Redis miss → PostgreSQL → Redis → ClientPostgreSQL supplies the durable mapping, the API warms Redis, and later opens can become cache hits.03Normal
Create a link
A user submits a new destination that needs a short code.
Client → Load balancer → API validation → PostgreSQL commit → ClientThe mapping is durable before the API returns the short URL. Read caching is not a substitute for this write.04Edge case
Unknown or expired link
Neither Redis nor PostgreSQL has an active mapping for the code.
Client → Load balancer → API → Redis miss → PostgreSQL → API → ClientThe API returns 404 for an unknown code or 410 for an expired resource instead of redirecting.Traffic & capacity
4 experiments01Healthy
Healthy baseline
Normal demand fits across the API, cache and database tiers.
Watch: Redis serves most reads. PostgreSQL receives about 1.16K operations/s, so queues and errors should remain near zero.02Degraded
Low cache hit rate
A low hit rate sends more read work to PostgreSQL.
Watch: More reads reach PostgreSQL. Watch database utilization and pending work rather than assuming an online cache is enough.03Overload
Viral traffic
A viral burst exceeds API dispatch capacity.
Watch: The two-replica API tier can dispatch only 12K requests/s. Its queue grows before downstream capacity can help.04Stress
Write-heavy traffic
Write-heavy traffic bypasses the read cache and pressures storage.
Watch: Writes bypass the read cache and reach PostgreSQL. A high cache-hit rate cannot remove durable write demand.Failure & resilience
4 experiments01Failure
Lose Redis
Losing Redis sends all dispatched work to PostgreSQL.
Watch: Every dispatched request falls back to PostgreSQL. Database demand rises above capacity, pending work grows and requests begin to fail.02Degraded
Lose an API replica
One API replica cannot dispatch the full incoming workload.
Watch: The surviving replica cannot dispatch the 8K requests/s workload. API pending work accumulates even when Redis is healthy.03Bottleneck
Slow PostgreSQL
Reduced database service capacity creates pending work.
Watch: The normal 1.16K operations/s database demand now exceeds service capacity. Database queues expose the new bottleneck.04Resilient
Outage with headroom
Database headroom absorbs the Redis fallback workload.
Watch: All 8K requests/s reach PostgreSQL and still fit. This shows that a dependency outage causes overload only when fallback capacity is insufficient.Ready to test these conditions?
Experiment runs every preset for 30 simulated seconds and records comparable evidence.