Easy · Core building blocks
URL shortener
People paste a long web address and get back a short one. Millions of other people then tap that short link, so reading is almost everything. Keep every tap fast, and never lose a link. Practise this easy system design problem for free with a Google or GitHub account.
The brief
People paste a long web address and get back a short one. Millions of other people then tap that short link, so reading is almost everything. Keep every tap fast, and never lose a link.
Think of a link shortener like Bitly.
Users, scale and requirements
- Who uses it
- 50 million people a month
- Audience in plain numbers
- 50,000,000 people per month
- Normal peak
- ≈ 5,000 requests per second
- Request mix
- Read: 99%; Write: 1%
- Speed for 99 of 100 requests
- Read: ≈ 200 ms; Write: ≈ 200 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $12,000
- Data at rest
- ≈ 1.5 TB
- Where users are
- North America: 70%; Europe: 30%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Write: 3,600 seconds
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- Short codes are 7 characters. Each stored link uses about 0.5 KB including its metadata (approx.).
- About 20 new links a second on average (≈ 50 million a month, approx.).
- One app server handles about 1,000 requests a second (approx.).
Questions that shape the design
Can a short link change after it is made?
No. A link never changes once created, so saved answers never go out of date and caching is safe.
How many people tap a link compared with people who make one?
About 99 taps for every 1 new link. This is a read-heavy system.
Do we count clicks live?
No. Click counts can arrive a few minutes late. The redirect itself must be fast.
The traffic day
Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
19:30 · Viral spike
A post blows up. Traffic climbs to several times normal within minutes.
Traffic reaches 3 times the scheduled load; rises over 600 seconds, holds for 3,600 seconds and eases over 3,600 seconds.
12:10 · Cache stampede
The cache empties (restart, purge, mass expiry) and every request rushes to the database at once.
Recovery window: ≈ 300 seconds.
What a strong design has to handle
- One server handles about 1,000 requests a second. At 5,000 that is 5 servers with no spare room, so plan for about 6 or more (the 3 from the intro is not enough here). What happens when a link goes viral?
- A longer cache time means more hits and less cost. Links never change, so an hour or a day is safe here.
- Collapsing misses stops a thousand people asking for the same cold link from hitting the database together.
Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.
Concepts to practise
Related problems
- Medium
Search autocomplete
As people type, they expect suggestions after every letter, in the blink of an eye. Most people type the same popular beginnings. When news breaks, one phrase suddenly dominates.
- Hard
Object storage service
Customers store billions of files, from tiny pictures to huge videos, and fetch them by name. The service must never lose a file, scale without a limit and stay cheap. Most files are written once and rarely read again.
- Easy
News site
You run a news site. Millions read the same few stories, and when something big happens almost everyone opens the same page in the same minute. Editors publish all day, and readers expect fresh headlines.
- Medium
Music streaming
People search for songs, build playlists and press play. The audio is the heavy part, and a hit song is played by millions at once. Playback must not stutter, even when part of your system fails.