Resource Estimation
In one line: this estimation is careful — it computes seconds in an average month rather than assuming 30 days. And then it discards its own answer in the one place it matters.
Assumptions
- Write-to-read ratio of 1:100
- 200 million new shortening requests per month
- 500 bytes per entry
- Entries expire after five years
- 100 million daily active users
Storage
200M/month x 12 months x 5 years = 12 billion entries 12,000,000,000 x 500 bytes = 6 TB
Six terabytes over five years — the whole system fits on one machine
This is worth sitting with, because it inverts everything the module has trained you to expect.
6 TB is a single commodity SSD array. Not a cluster, not a tier — a machine.
So the entire dataset of a globally-used URL shortener, five years deep, would fit in the RAM of a large server if you were willing to pay for it. And Lesson 3's cache estimate will show that the hot subset fits in 66 GB.
That reframes every subsequent design decision. Sharding, replication, and consistent hashing appear in Lesson 13's evaluation — and none of them is forced by volume. They are there for availability and request throughput, which is a different argument and should be made as one.
When a design proposes sharding, check whether the data actually needs it. Here it does not; the reasons are real but they are not size.
Query rate
Redirections/month = 200M x 100 = 20 billion Seconds/month = 30.42 x 24 x 3600 = 2,628,288 Write QPS = 200,000,000 / 2,628,288 = 76 URLs/second Read QPS = 76 x 100 = 7,600 URLs/second
Bandwidth
Incoming = 76 x 500 bytes x 8 = 304 Kb/s Outgoing = 7,600 x 500 bytes x 8 = 30.4 Mb/s
Thirty megabits per second, against Instagram's fifty terabits
Instagram 50,280,000 Kb/s TinyURL 30,400 Kb/s <- 1.65 MILLION times smaller
A single server's network interface handles this with 99.9% headroom.
And note the outgoing figure is generous, because a redirect does not return 500 bytes. It returns an HTTP 302 with a Location header — a few hundred bytes at most, and the long URL itself is typically under 100. The real egress is lower still.
There is no bandwidth problem here, and saying so confidently is the right move — it directs attention to where the difficulty actually is.
Memory
Applying the 80/20 rule, assuming 20% of URLs generate 80% of the traffic:
Daily redirections = 7,600 x 3,600 x 24 = 0.66 billion Cache = 0.2 x 0.66B x 500 B = 66 GB
The rule cited and the calculation performed are different things
Read the two carefully.
The rule stated: "20% of URLs generate 80% of the traffic." That is a statement about the distinct URLs in the system.
The calculation performed: 20% of daily requests × 500 bytes.
Those are not the same quantity, and applying the rule as stated gives a very different answer:
As stated: 20% of 12 billion URLs = 2.4 billion entries = 1.2 TB
As computed: 20% of 0.66 billion reqs = 131 million entries = 66 GB
-------
18x apart
So which is right? Neither derivation is clean, because the quantity you actually want is the number of distinct URLs accessed in a day, and that figure appears nowhere in the estimate. It is bounded above by 0.66 billion requests and below by however much repetition there is.
66 GB is a plausible cache size — it holds 131 million mappings, which for a service where traffic is heavily skewed toward recent and viral links is probably ample. The number is fine; the reasoning does not support it.
The habit: when you invoke a distribution rule, apply it to the quantity the rule is about. The 80/20 rule concerns items and their popularity, not a fraction of a request count.
A cleaner derivation would be: estimate distinct URLs accessed per day, take the head of that distribution, and size for it. Say which quantity you are taking 20% of, and the estimate becomes checkable.
Servers — and the contradiction
Assuming a peak load of 100 million requests per second (using DAU as a proxy) and a server capacity of 64,000 RPS:
100,000,000 / 64,000 = 1,562.5 ~= 1.6K servers
13,141x — the largest self-contradiction in the module
The query-rate section, two sections earlier, computed the read rate carefully:
Query rate section: 7,600 requests/second <- computed, correct
Server section: 100,000,000 requests/second <- asserted
------------------------------
Factor: 13,141x
Substituting the figure the chapter itself derived:
7,600 / 64,000 = 0.12 servers
About one-eighth of a machine.
This is the fifth appearance of this pattern in the module — Yelp at 86,400×, Uber, Newsfeed at 8,640×, Instagram at 4,320×, and now 13,141×. It is the largest, and the most avoidable, because the correct rate is on the same page.
The DAU-as-RPS convention assumes every one of 100 million daily active users issues a request every second, all day. At 20 billion redirections a month, the average user performs about 6.6 redirections per day — roughly one every four hours, not one per second.
What would a real peak look like? Diurnal traffic peaks at perhaps 3–5× the mean:
7,600 QPS x 5 = 38,000 QPS -> less than ONE server
So the honest answer is: one server handles the entire load, and you run several for availability, not capacity.
That is the correct conclusion, and it is more interesting than 1,600 servers. It means every scaling mechanism in Lesson 13's evaluation — sharding, consistent hashing, horizontal scaling — is justified by fault tolerance and geographic distribution, not by throughput. Which is a perfectly good justification, and a completely different one.
When your corrected estimate says "one server," the design conversation changes from how to scale to why you are running more than one.
The summary table
| Quantity | Published | Corrected |
|---|---|---|
| New URLs | 76/s | 76/s — correct |
| URL redirections | 7.6 K/s | 7.6 K/s — correct |
| Incoming data | 304 Kb/s | 304 Kb/s — correct |
| Outgoing data | 30.4 Mb/s | 30.4 Mb/s — generous, a 302 is smaller |
| Storage (5 years) | 6 TB | 6 TB — correct |
| Cache memory | 66 GB | Plausible size, muddled derivation |
| Servers | 1,600 | ~0.12 by load; a handful for availability |
Key takeaway
Six of seven figures are correct, and the estimate shows real care — using 30.42 days rather than 30. 6 TB over five years fits on one machine, so the sharding in the evaluation is justified by availability rather than volume, and that distinction should be made explicitly. The memory estimate cites a rule about URLs and applies it to requests, an 18× difference; 66 GB is a plausible size with unsupported reasoning. And the server count contradicts the chapter's own read rate by 13,141× — the largest such gap in the module, with the correct figure two sections earlier. Corrected, one server carries the entire load, which changes the conversation from how to scale to why you run more than one.
The storage figure is similarly undramatic — a billion rows at a few hundred bytes fits on one modern SSD. This is a small system by data volume and a demanding one by read latency, and saying that is more useful than quoting either number alone.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "200 million URLs a month for five years is 12 billion entries at 500 bytes — 6 TB. At a 1:100 write-to-read ratio that's 76 writes and 7,600 reads per second." |
| L5 | Notices the scale: "all of these are small — 6 TB fits on one machine and 30 Mb/s is nothing. So this isn't a capacity problem; the interesting constraints are on the identifier space." |
| Staff+ | Corrects and reframes: "the chapter computes 7,600 QPS and then sizes servers from 100 million, which is the DAU count reused as a rate — a factor of 13,000. At the derived rate it's about an eighth of a server, and even a 5x diurnal peak is under one. So every scaling mechanism in the design is justified by availability and geographic distribution rather than throughput, and I'd say so explicitly. I'd also flag the cache derivation: it cites 'twenty percent of URLs' and then takes twenty percent of requests, which differ by eighteen-fold. 66 GB is a fine cache; the reasoning doesn't get you there." |
Next: the building blocks and the API.