It's a quick, rough calculation that converts user counts into the numbers that actually drive architecture: QPS, storage, and bandwidth.

We do it because the scale determines the design. A system doing 30 writes per second and one doing 30,000 look identical on a whiteboard but need completely different architectures — one database versus a sharded cluster with queues.

The goal is order-of-magnitude accuracy, not precision. Being within 10x is a success, because we're deciding between "one server" and "one thousand servers".

A day is actually 86,400 seconds, but 100,000 is 10⁵ — so dividing by it just means removing five zeros, which you can do mentally.

For example, 1 billion events per day becomes 10,000 per second instantly.

The approximation overestimates by about 16%, which is harmless and conservative — you end up designing with a little extra headroom rather than under-provisioning.

It's the number of reads for every write. Social media and content systems are typically 100:1 or higher; chat is roughly 1:1; logging and metrics systems are write-heavy.

It matters because reads and writes scale very differently. Reads can be cached, replicated, and served from a CDN — they scale outward cheaply. Writes must reach the source of truth and stay durable and consistent, so they scale much harder.

A read-heavy system at 60,000 QPS is a caching problem. A write-heavy system at the same QPS is a sharding and durability problem. Same number, entirely different architecture.

Assume 300 million daily active users, 2 tweets each per day, and 200 timeline reads each per day.

Writes: 300M x 2 = 600M tweets/day, and dividing by 100,000 gives 6,000 writes/second.

Reads: 300M x 200 = 60B/day, which is 600,000 reads/second.

Storage: at 1 KB per tweet that's 600 GB/day of text. But if 10% of tweets carry a 1 MB image, media adds 60 TB/day — a hundred times more than the text.

The conclusion is that media belongs in object storage behind a CDN, with only URLs in the database, and the 100:1 read ratio means timelines must be cached or precomputed.

Traffic isn't evenly spread across 24 hours. Most users are active during a few peak hours, so the busiest moment can be two to three times the daily average.

If you provision for the average, the system falls over exactly when the most people are trying to use it.

So we take the average QPS and multiply by 2 or 3 to get peak QPS, and size the system against that number. Some systems have far spikier patterns — ticket sales or flash sales can be 10x or more, and those need explicit surge handling.

Raw, yes — 3 TB fits on a single disk. But 3 TB is not what you'll actually provision.

With a replication factor of 3 for durability and availability, it becomes 9 TB. Indexes commonly add another 50-100%, pushing it toward 15 TB. Backups and retention add more on top.

So the practical rule is that real storage is roughly 3-5x the raw estimate. At that point you'd likely still use a single primary with replicas rather than sharding, but you'd want to check growth rate — if data doubles yearly, you're planning a sharding strategy now, not later.

Divide peak QPS by what one server can handle, then add headroom.

A typical app server handles somewhere between 1,000 and 10,000 simple requests per second, so 5,000 is a reasonable working assumption. For 1.2 million peak reads per second, that's 1,200,000 ÷ 5,000 = 240 servers.

Then add capacity for failures, rolling deployments, and traffic growth — so you'd plan for 300 or more. You should also state the assumption explicitly, because if the interviewer says each request is expensive and a server only handles 500 QPS, the answer changes by 10x.

Start with the 80/20 rule: roughly 20% of the data serves 80% of the requests. So cache the hot 20% of the working set rather than everything.

If a day's worth of text data is 600 GB, caching 20% means about 120 GB of cache. At around 64 GB of usable RAM per node, that's two to four cache nodes, plus replicas for availability.

You also need to decide the time window — caching the last day is very different from caching the last year — and pick an eviction policy, usually LRU, so the cache naturally keeps what's actually hot.

Assume 100 million new URLs per month, which is about 3.3 million per day.

At 500 bytes per row — short code, long URL, creation time, owner, expiry — that's about 1.65 GB per day.

Over five years: 1.65 GB x 365 x 5 ≈ 3 TB.

The useful insight is how small that is. Writes work out to only about 33 per second. So a URL shortener isn't really a scale problem at all — the interesting parts are generating short codes without collisions and keeping redirect latency low.

Ingress is data coming into your system, such as uploads. Egress is data leaving it, such as downloads and API responses.

Egress usually matters more for two reasons. First, most systems are read-heavy, so far more data flows out than in. Second, cloud providers typically charge little or nothing for ingress but charge significantly for egress — it's often one of the largest line items on a cloud bill.

This is a major reason CDNs exist: serving bytes from edge caches is cheaper than serving them from your origin, and it reduces load on your servers at the same time.

It immediately rules out a single database. A typical SQL node handles a few thousand writes per second, so 500,000 means you need on the order of 100 or more write nodes — which means sharding is mandatory, not optional.

It also suggests putting a queue like Kafka in front to absorb bursts and decouple ingestion from persistence, and it points toward storage engines optimized for write throughput, such as LSM-tree based systems like Cassandra.

And it raises a design question worth asking: does every write need to be immediately durable and consistent, or can some be batched and processed asynchronously? At this volume, that decision has a big impact on cost.

The most frequent one is estimating from total registered users instead of daily active users, which overshoots by three to ten times and leads to over-engineering.

Others include designing for average traffic instead of peak, forgetting to split reads from writes and therefore missing the biggest architectural signal, and ignoring replication so the real storage is three times larger than calculated.

Two more are worth mentioning: treating media like text, which is off by a factor of a thousand, and chasing exact numbers instead of rounding — that burns time and adds nothing, since the whole point is magnitude.

Finally, keeping assumptions silent. If you don't say them out loud, the interviewer can't follow your reasoning or correct a wrong premise early.