How Estimation works

Before you start

• Requirements

  Estimates and APIs start from an agreed list of what the system must do.

  Open lesson

Why it matters

“100 million” sounds huge until units show whether it creates a traffic problem or only a storage problem. The same shortener can be quiet on creates and heavy on redirects, while viral links can turn a 10:1 read ratio into 1000:1. The estimate must decide whether one primary absorbs creates and what cache hit rate keeps redirect reads within its capacity.

Assume 100 million new short links a month and ten redirects per new link. Keep the data for five years. A mapping row is about 500 bytes.

Input

links_per_month = 100_000_000, reads_per_link = 10, row_bytes = 500, years = 5

Output

[39, 386, 3000]

For 100 million links a month, ten redirects per link, 500-byte rows, and five years, derive 39 writes/s, 386 reads/s, and 3 TB, then test the viral 1000:1 read case against one primary’s limits.

A 30-day month has about 2.6 million seconds. Dividing 100 million new links by that gives about 39 creates per second; multiplying by ten redirects per link gives about 386 reads per second. Keeping the units beside every value prevents a monthly total from being compared with a per-second limit.

Five years contains 6 billion mapping rows. At 500 bytes each, that is about 3 TB before indexes and replicas. Compare 39 writes per second and 3 TB with one machine separately; if redirects rise to 1000 per link, recalculate reads without pretending creates or stored rows also grew.