Estimate Before You Architect

Estimates tell you which problems are real

The requirement brief assumes one million new links and one hundred million redirects per day. Are those numbers large enough to require partitioning? Would all link records fit on one machine? Is network bandwidth or storage likely to dominate?

Without estimates, every technology sounds potentially necessary. Back-of-the-envelope calculation gives the design proportions.

The goal is not a perfectly accurate forecast. The goal is to distinguish:

10 requests/second from 100,000 requests/second
10 gigabytes from 10 petabytes
one machine from a globally distributed fleet

Keep a small unit vocabulary

Use approximations that are easy to calculate and explain:

1 day       ≈ 100,000 seconds   (actual value: 86,400)
1 KB        ≈ 1,000 bytes
1 MB        ≈ 1,000 KB
1 GB        ≈ 1,000 MB
1 TB        ≈ 1,000 GB

Powers of two matter for some implementation details, but decimal approximations are usually clearer for capacity reasoning. State which convention you use and remain consistent.

Always carry units through the equation. A bare result such as 12,000 is ambiguous; 12,000 redirects/second can guide a decision.

Convert daily traffic to requests per second

The approximate formula is:

average requests/second = requests/day ÷ seconds/day

For 100 million redirects per day:

100,000,000 redirects/day ÷ 86,400 seconds/day
≈ 1,157 redirects/second on average

Traffic is rarely uniform. If we assume a peak of ten times the average:

peak redirects ≈ 11,570/second
round to roughly 12,000/second

For one million creations per day:

1,000,000 ÷ 86,400 ≈ 12 creations/second average
10× peak ≈ 120 creations/second

The system is read-heavy: redirects outnumber creations about 100 to 1. That fact makes the read path, not the write path, the first candidate for caching and horizontal scaling.

Average is not capacity

An average hides bursts. Morning traffic, a popular shared link, or a regional event may produce far more than the daily average. The peak multiplier is an assumption that should eventually be replaced by measurement, but ignoring peaks entirely creates a predictably fragile design.

Estimate retained storage

Assume one stored mapping occupies roughly 500 bytes after accounting for:

• the short code;
• the destination URL;
• timestamps and expiration;
• database record and index overhead.

At one million new mappings per day:

500 bytes/mapping × 1,000,000 mappings/day
= 500,000,000 bytes/day
≈ 500 MB/day

For five years:

500 MB/day × 365 days/year × 5 years
≈ 912,500 MB
≈ 0.9 TB

Round that to approximately 1 TB of primary data. Three durable copies would bring raw storage near 3 TB before backups, logs, and operational headroom.

This is substantial but not automatically a reason to build a complex sharded database on day one. The estimate tells us to preserve a path to partitioning while beginning with the simplest storage that meets current load and reliability needs.

Estimate network throughput

Suppose the redirect response, including headers, averages 1 KB. At a peak of 12,000 redirects per second:

12,000 responses/second × 1 KB/response
= 12,000 KB/second
≈ 12 MB/second
≈ 96 megabits/second

The conversion to bits multiplies bytes by eight. Real traffic also includes requests, encryption overhead, retries, health checks, and internal service traffic. The estimate provides an order of magnitude, not a network invoice.

If the service returned large images instead of small redirects, bandwidth and CDN strategy would dominate much earlier. Workload shape matters more than fashionable architecture.

Make sure the identifier space is large enough

A short code using lowercase letters, uppercase letters, and digits has 62 possible symbols at each position. A seven-character code provides:

62⁷ = 3,521,614,606,208 possible codes

That is about 3.5 trillion combinations—far more than the approximately 1.8 billion links created over five years at one million per day.

This does not make random generation collision-free. It makes collisions increasingly unlikely while the occupied fraction is small. The creation path must still detect a duplicate code and retry or use a generation strategy that guarantees uniqueness.

Estimate memory for a cache

Caching every retained record would eventually require approximately the same raw data size as the database, which is unnecessary. Popularity is usually uneven: a small portion of links may receive a large portion of redirects.

Suppose we provision 20 GB for cached mappings and estimate 500 bytes per entry:

20,000,000,000 bytes ÷ 500 bytes/entry
≈ 40,000,000 cached mappings

That calculation does not promise a particular hit rate. It tells us how many entries fit. Observed traffic would determine whether those entries cover enough reads to justify the cache and what eviction policy works.

Every estimate should answer “so what?”

An estimate that changes no decision may be unnecessary. Conversely, a decision justified only by “large scale” probably needs a number.

Precision should match the inputs

Writing 11,574.074 redirects/second suggests false accuracy when the traffic and peak factor are assumptions. Prefer:

about 1.2K redirects/second average
about 12K redirects/second at an assumed 10× peak

Keep a visible assumptions table so another person can change one input and recompute the consequences.

Practice: estimate a notification service

Assume:

50 million notifications/day
5× peak over average
2 KB per queued notification
retain delivery records for 30 days
each worker sends 100 notifications/second

Estimate:

1. average and peak notifications per second;
2. temporary storage if one full day accumulates in the queue;
3. retained delivery-history storage before replication;
4. the minimum worker count at peak, then add reasonable headroom;
5. which assumption you would most want to validate in production.

Write units beside every intermediate result and finish each estimate with the architectural question it helps answer.

Chapter checkpoint

You should now be able to move from a workload statement to approximate QPS, storage, bandwidth, and namespace size. More importantly, you should be able to say why each number matters to the design.