Design a URL Shortener, stage 1 of 9: model
Estimate the load
Before drawing any boxes, work out how much traffic and data this system really has. Rough numbers are enough: you only need to know whether something fits on one machine or needs many.
System so far· 5 parts
Select a component to see what it is responsible for and which state it owns.
- 1Redirect service → Postgres: Look up code
- 2Customer dashboard → Links API: Create, edit, disable
- 3Links API → Postgres: Insert with unique code
What you need to know
Requirements usually come as monthly or daily totals. Systems fail per second, so convert.
A month has about 2.6 million seconds (30 days × 86,400 seconds). Divide a monthly total by 2.6 million to get the average per second. Traffic isn't flat, so multiply by the peak factor to get the rate you actually have to handle.
Work it out
100 million new links a month. About how many links are created per second, on average?Work it out
10 billion redirects a month, with peaks at 5× the average. About how many redirects per second at peak?Now storage. Estimate the size of one record, then multiply by how many you add per year.
A link row holds a 7-character code, the destination URL (usually 100 to 200 bytes, sometimes much longer), an owner id, timestamps and a status. With index overhead, 500 bytes is a reasonable round number. 100 million links a month is 1.2 billion a year.
Work it out
1.2 billion links a year at 500 bytes each. About how much storage per year?Compare your numbers with what one machine can do. These are rough figures for a well-provisioned server, worth remembering as orders of magnitude:
Work One server handles roughly Postgres lookups by primary key tens of thousands per second Postgres small inserts thousands per second Redis gets around 100,000 per second Disk several terabytes Check
Put your three numbers (190 writes/s at peak, 19,000 reads/s at peak, 600 GB/year) next to that table. What do they tell you?