Back-of-the-Envelope Rates & Storage

Foundations

Estimation turns product numbers into the units machines are judged by: requests per second and bytes stored. A month has about 2.6 million seconds, so a monthly count divided by 2.6 million becomes a rate, and storage is rows times bytes per row times years kept. Compare each result with one machine: a database primary handles thousands of simple writes per second, and one large disk holds a few terabytes.

Keep reads and writes apart, because their ratio decides the next component: a read-heavy service wants a cache, and a write-heavy one wants a faster or split store. Write the unit beside every number. Comparing a monthly total with a per-second limit is the classic estimation mistake.

Take a service that stores 10 million new records a month, reads each 20 times, keeps them 3 years, and uses 1 KB per record. Writes are about 10,000,000 / 2,600,000 ≈ 4 per second and reads about 77. Storage is 10M × 36 months × 1 KB = 360 GB. Every number fits one machine, so nothing here forces sharding.

• Requirements

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

  Open lesson

Case Scenario

To see how estimation turns monthly totals into machine-sized numbers, consider a URL shortener like bit.ly with 100 million new short links a month, ten redirects per link, and 500-byte mapping rows kept for five years. That is about 39 writes and 386 reads per second, and 3 TB of rows.

“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.