Loading…

The decisions that matter

Key the link store by short code.The redirect arrives with only the code, so the source of truth should answer that lookup directly.
Generate or claim codes with a duplicate-refusing write.It protects counters, random codes, hashes and aliases from races and overwrites.
Put cache and edge reads in front of the store.Redirects outnumber creates by about a hundred to one in the brief.
Send 302 or 307 with explicit short caching.Clicks keep returning to the service, and removed links stop quickly.
Count clicks asynchronously and scan links in the background.The redirect remains a redirect, even when analytics or abuse checks are slow.

Architecture diagramThe final design at a glance

The complete shortener: durable link creation, a cached redirect path, asynchronous counts, abuse checks and regional replicas. Dashed lines are asynchronous or background work.

Diagram as text

Components: Owner app (Client); Browser opening /{code} (Client); CDN and edge cache (CDN); API gateway (API gateway); Create service (Service); Redirect service (Service); Code allocator (Service); Regional link cache (Cache); Links store by code (NoSQL DB); Click event log (Queue); Counts pipeline (Analytics); Threat checks (External API). Connections: Owner app → API gateway (create, delete, stats); API gateway → Create service; Create service → Code allocator (claim code); Create service → Links store by code (write link); Create service → Regional link cache (warm), asynchronous; Create service → Threat checks (check destination); Browser opening /{code} → CDN and edge cache (GET short link); CDN and edge cache → Redirect service (miss or no edge copy); Redirect service → Regional link cache (lookup); Redirect service → Links store by code (miss fallback); Redirect service → Click event log (click), asynchronous; Click event log → Counts pipeline (aggregate), asynchronous.

Understanding the problem

A URL shortener has two jobs. Creating a link is an authenticated write: validate the destination, claim a code, save the link and show the owner the short URL. Opening a link is an anonymous read: a browser asks for /{code} and should be redirected quickly worldwide. The hard parts are code uniqueness, a read path that handles far more redirects than creates, lifecycle changes across caches and abuse control because short links hide their destination.

The practice brief already names the public URL shortener variant: signed-in owners create and manage links; anyone can open a short link. Confirm that the destination is fixed after creation, that custom domains and detailed analytics are out of scope, and that the one-minute deletion rule matters as much as redirect speed.

Functional requirements

CoreCreate a short link for a long URL, optionally with a custom alias and an expiry date.
CoreAnyone who opens a short link is sent on to the long URL, with no account needed.
CoreOwners see how many times each of their links was clicked.
CoreOwners can delete their links, and support can disable a link reported as harmful.
Below the lineList all of your links, newest first.
Below the lineExport click counts.
Below the lineShow a QR code for a short link.
Below the lineEditing a link’s destination after it is created.Changing destinations breaks the trust model and is explicitly out of scope.
Below the lineCustom domains and branded links.They add DNS, certificates and tenant policy without changing the core redirect design.

Non-functional requirements

ConsistencyA short link only ever points where its owner chose: no two links share a code, and a code is never reused.
LatencyRedirects are fast: about 100 ms at the 99th percentile, worldwide.
AvailabilityRedirects stay available (99.99%), even when a whole region is down.
ConsistencyA deleted, disabled or expired link stops working everywhere within about a minute.
QualityClick counts may lag by up to a minute.
SecurityLinks are unlisted: holding one short link must not help anyone find other people's links.

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 100 million new links a day.
ScaleAbout 10 billion redirects a day; one viral link can draw 50,000 clicks a second.
ScaleLinks are kept for 5 years unless their owner sets an earlier expiry.
ScaleUsers all over the world; the service runs in several regions.

Out of scope

Out of scopeDetailed analytics (countries, referrers, devices).
Out of scopeSign-up, plans and billing.

Check yourself

Why is editing a destination after creation a useful scope cut?
Show answerHide answer
It keeps one code tied to one owner-chosen destination for its whole life. Without edits, cache invalidation, abuse review and user trust are simpler, and the brief says edits are out of scope.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Use the brief’s givens to decide what must scale and what can stay simple. The derived arithmetic is illustrative: exact storage depends on URL length, metadata and replication, but the direction is stable.

Back of the envelope from the brief

Quantity	Value	What it means
Creates	Brief: 100 million a day; about 1,200 per second	100 million divided by 86,400 seconds. Create is important, but it is not the dominant path.
Redirects	Brief: 10 billion a day; about 116,000 per second	10 billion divided by 86,400 seconds. Reads are about 100 times writes.
Busy peak	About 300,000 redirects per second	An illustrative 2.5 times the average redirect rate from the family sample.
One viral link	Brief: 50,000 clicks per second	A single key can be the hot spot, even when the overall service is healthy.
Links kept	Brief: 5 years; about 182.5 billion links	100 million a day times 365 days times 5 years. The store needs partitions and durable copies.
Storage	About 90 TB before copies	182.5 billion links times an illustrative 500 bytes each is about 91 TB.
Code space	Base62^6 is about 57 billion; Base62^7 is about 3.5 trillion	Six characters are too few for 5 years. Seven characters leave illustrative headroom before aliases and skipped codes.
Hot-link memory	About 1 TB	If an illustrative 1% of retained links are hot, 1.825 billion links times 500 bytes is about 913 GB.
Latency budget	Brief: about 100 ms at p99 for redirects	Put the lookup near the user and keep counting, scanning and owner APIs out of the redirect path.

Architecture diagramThe load shape from the brief

Read:Learn: Numbers and capacity estimation Learn: Read-heavy

Try it: The numbers that shape the designGuided practice · URL shortener, Public URL shortener · Mid-level

Check yourself

Which number most strongly changes the architecture?
Show answerHide answer
The redirect rate: about 10 billion a day, with one link able to take about 50,000 clicks a second. It pushes the design toward cache, edge serving and hot-key handling.

Core entities

Keep the durable model small. The link record is the truth for redirects and lifecycle. Counts, scans and owner listings sit beside it, so one hot click stream does not update the link row on every redirect. A key-value or wide-column store keyed by code is a natural fit; a relational store split by code can also work if it can enforce one row per code.

The records that matter

Entity	Key fields	Why it exists
Link	`code`, `long_url`, `owner_id`, `created_at`, `expires_at`, `status`, `home_region`	The source of truth for one short link and the redirect lookup key.
Owner index	`owner_id`, `created_at`, `code`	Lists a user’s links without scanning all codes.
Alias claim	`alias` or the same `code` key	Makes custom aliases go through the same duplicate-refusing path as generated codes.
Click aggregate	`code`, `minute`, `clicks`	Stores counts produced by the analytics pipeline, not by the redirect itself.
Abuse decision	`code`, `verdict`, `reason`, `decided_at`	Lets support and scanners disable a link and explain the warning page.

Read:Learn: Data model design Learn: Storage choice justification Learn: Partitioning, sharding and consistent hashing

Try it: The link record and where it livesGuided practice · URL shortener, Public URL shortener · Mid-level

Check yourself

Why should click counts not be a column on the link row?
Show answerHide answer
A viral link would update the same row for every click, and every redirect would wait for that write. Counts belong in a separate aggregate fed by an asynchronous pipeline.

The API

The management API can be versioned and authenticated. The short link is a public HTTP redirect, because browsers, crawlers, chat apps and printed QR codes all need to follow it. Redirect status is a design choice: RFC 9110 (opens in a new tab) defines 301 and 308 as permanent and heuristically cacheable, while 302 and 307 are temporary and not in that default heuristic list. Use explicit cache headers because CDN products can add their own defaults.

A compact contract for the shortener

Call	Request	Response	Errors
`POST /v1/links`	`long_url`, optional `alias`, optional `expires_at`	`201` with `code`, `short_url`, `expires_at`	`400` invalid URL or alias; `401`; `409` alias taken
`GET /{code}`	No auth; public browser request	`302` or `307` with `Location` and `Cache-Control: no-store` or a very short `max-age`	`404` unknown; `410` expired or deleted; warning page for disabled
`DELETE /v1/links/{code}`	Owner or support auth	`204`; cache purge starts	`403` not owner; `404` unknown
`GET /v1/links/{code}/stats`	Owner auth	`200` with `clicks` and `as_of`	`403`; `404`; counts may lag

Read:Learn: API contract design Learn: Networking fundamentals

Try it: Shorten a link, open itGuided practice · URL shortener, Public URL shortener · Mid-level

Check yourself

Why not return {long_url} as JSON from GET /{code}?
Show answerHide answer
A short link is opened by ordinary browsers and other clients that understand HTTP redirects. Returning JSON requires a special client and breaks links in messages, email and print.

High-level design

Build the design around the two main flows. Create is a durable write with validation and a code claim. Redirect is a read that should finish fast without trusting any cache as the record.

Create and store a short link

A signed-in owner sends the long URL, optional alias and optional expiry. The create service validates the URL shape, asks the abuse checker for a quick decision, chooses or claims a code, writes the durable link record and warms the cache. If the cache warm fails, the link still exists: the first redirect falls back to the store and fills the cache then.

The client calls POST /v1/links through the API gateway with owner auth.
The create service validates the destination and runs a quick abuse lookup.
Generated codes come from the chosen code scheme; custom aliases go straight to the duplicate-refusing write.
The link store writes one row keyed by code, then optionally warms the cache and returns the short URL.

Architecture diagramCreate a short link

Create validates the destination, claims a code exactly once, writes the durable link and warms the cache.

Diagram as text

Components: Owner app (Client); API gateway (API gateway); Create service (Service); Fast abuse lookup (External API); Code source (Service); Links store (NoSQL DB); Cache warm (Cache). Connections: Owner app → API gateway (POST /v1/links); API gateway → Create service; Create service → Fast abuse lookup (check); Create service → Code source (candidate); Create service → Links store (conditional write); Create service → Cache warm (optional warm), asynchronous.

Read:Learn: API contract design Learn: Storage choice justification

Try it: Create and redirect, end to endGuided practice · URL shortener, Public URL shortener · Mid-level

Check yourself

If cache warming fails after the store write succeeds, is the link broken?
Show answerHide answer
No. The store is the source of truth. A later redirect misses the cache, reads the store, fills the cache and then redirects.

Serve a redirect fast

The redirect path is read-heavy and public. Put the CDN, regional redirect servers and a cache in front of the link store. On a cache hit, the service still checks the cached status and expiry before returning the redirect. On a miss, it reads the store by code, fills the cache and returns the same HTTP response. Unknown codes are cached briefly to absorb probing.

A browser requests GET /{code} at the nearest edge or load balancer.
The CDN may answer a very short-lived redirect for hot links if the lifecycle rule permits it.
A regional redirect service checks the cache by code and verifies status and expiry on the cached value.
On a miss, it reads the link store by code, fills the cache with the same bounded lifetime and returns the redirect.
It emits or buffers a click event after deciding the redirect; the person clicking does not wait for the analytics pipeline.

Architecture diagramRedirect read path

Design a URL shortener

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

The API

High-level design

Create and store a short link

Serve a redirect fast

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

04The API

05High-level design

Create and store a short link

Serve a redirect fast

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this