classic system design
Design a URL shortener
Generate short links, redirect at high read volume, and handle abuse without losing the simple core.
id generationread-heavy storageanalytics pipelineabuse controls
Prompt
Design a URL shortener for public links. The service must create short URLs, redirect users quickly, and give creators basic analytics.
Clarifying questions
- Are custom aliases required or only generated aliases?
- Do links expire, and can creators delete links?
- What analytics precision is needed for public dashboards?
Functional requirements
- Create a short code for a long URL.
- Redirect short-code requests to the target URL.
- Record aggregate click analytics by time bucket and referrer class.
Nonfunctional requirements
- Keep redirect p95 below 30 ms from edge to redirect response.
- Make short-code creation idempotent for client retries.
- Block obvious malware and phishing reports quickly.
Scale assumptions
- 100 million redirects per day.
- One million new links per day.
- Read traffic is at least 100x write traffic.
API sketch
- POST /v1/links { targetUrl, customAlias?, expiresAt? } -> { shortUrl }
- GET /{code} -> 301 or 302 redirect.
Data model
- links(code primary key, target_url, owner_id, status, created_at, expires_at).
- click_events(code, occurred_at, user_agent_family, referrer_class, country).
Architecture components
- Creation service generates or reserves codes and stores metadata.
- Redirect service reads through a regional cache backed by primary storage.
- Analytics events are written asynchronously to an append-only stream.
Bottlenecks
- A viral link can dominate redirect cache and analytics writes.
- Custom alias reservation needs a strong uniqueness check.
Failure modes
- Analytics stream unavailable: redirect succeeds and buffers bounded events.
- Cache miss storm: redirect service rate-limits origin fetches per code.
- Abuse report: link status flips to blocked and cache is invalidated.
Observability
- Redirect latency by cache hit or miss.
- Creation conflicts, blocked redirect count, analytics lag.
Security / privacy
- Validate and normalize target URLs before storage.
- Keep raw IP addresses out of long-term analytics unless a reviewed policy requires them.
Cost considerations
- Redirect path cost is dominated by cache egress and hot-link analytics writes.
- Long analytics retention needs downsampling or bucketed aggregation.
Tradeoffs
- Random codes avoid central counters but make custom code collision handling visible.
- 301 redirects improve client caching; 302 redirects preserve future target changes.
Rubric
| Criterion | Weight | Evidence |
|---|---|---|
Separates product behavior from infrastructure assumptions before drawing boxes. clarification | 10 | The answer names users, write paths, read paths, retention, and what is explicitly out of scope. |
Turns traffic and data assumptions into concrete sizing constraints. scale | 15 | Uses RPS, storage growth, hot-key risk, fanout, latency budget, or memory budget where relevant. |
Draws clear service, cache, queue, and storage boundaries with reasons for each split. architecture | 20 | The component diagram has one owner per responsibility and names the synchronous path. |
Defines durable state, indexes, keys, and idempotency records. data | 15 | Tables or collections include primary keys, lookup paths, TTLs, and consistency expectations. |
Names failure modes and the recovery behavior users see. failure | 15 | Covers partial outages, retries, duplicate work, stale reads, overload, and backfill. |
Defines the small set of metrics and traces needed to debug the design. observability | 10 | Includes SLIs, saturation metrics, queue lag, error classes, and an alert tied to user harm. |
Explains what is being sacrificed and why that sacrifice fits the prompt. tradeoffs | 15 | Compares at least two viable designs and names the losing design's advantage. |