Back-Of-The-Envelope Estimation / Capacity Planning

Summary

Back-of-the-envelope estimation is a quick way to sanity-check system designs and identify likely infrastructure needs. It is not meant to produce exact figures; getting within roughly an order of magnitude is often enough to guide decisions.

The video demonstrates how to estimate service or database load, then applies the same approach to storage capacity.

Estimating Requests per Second

Useful inputs include:

• Daily active users (DAU): If only monthly active users (MAU) are known, estimate what fraction use the service on a typical day.
• Usage per active user: Estimate how often users perform the action being designed for. For example, not every social media user posts.
• Peak-to-average scaling factor: Account for periods when traffic is higher than average, such as commute hours or weekend nights.

Example: Tweets Created per Second

The video uses illustrative, non-official figures:

• 300 million MAU, with 50% active daily → 150 million DAU
• 25% of DAU tweet, averaging two tweets each → 0.5 tweets per DAU
• Peak traffic is estimated at twice the average

The estimate is:

150 million × 0.5 × 2 ÷ 86,400 seconds per day

Rounding 86,400 to 100,000 makes the calculation easier and gives approximately 1,500 tweets per second at peak.

This estimate can inform design choices. For example, if a service needs one million requests per second and each server handles about 10,000, the rough estimate suggests around 100 servers behind a load balancer. Conversely, a database load of about 10 queries per second might be manageable on one database server for a while, without immediately requiring sharding or caching.

Techniques for Simplifying Calculations

• Write large values in scientific notation. For example, 150 million becomes 1.5 × 10⁸.
• Round numbers to convenient values. The example rounds 86,400 seconds per day to 10⁵.
• Group powers of ten separately from other numbers. Multiply the ordinary factors, then combine exponents.
• Memorize common powers of ten and unit conversions. For instance, 10¹² is a trillion bytes, or roughly a terabyte for this kind of estimate.
• Ignore minor precision details. The video treats a kilobyte as 1,000 bytes rather than 1,024 because that level of precision is unnecessary for a rough estimate.

Estimating Multimedia Storage

The storage example assumes:

• 150 million tweets per day
• 10% contain a picture averaging 100 KB
• 1% contain a video averaging 100 MB
• Three copies of each media file
• Media retained for five years
• A rough 400-day year for simpler arithmetic

Pictures

The estimate multiplies daily tweets by the share with pictures, average picture size, retention period, and replication factor. The result is approximately 9 petabytes of picture storage.

Videos

A 100 MB video is about 1,000 times larger than a 100 KB picture, while videos are estimated to appear one-tenth as often. Thus, video storage is about 100 times picture storage: approximately 900 petabytes.

Main Lesson

Use rough calculations to expose the scale of a system’s requirements and validate design choices. Avoid overemphasizing precision: a reasonable estimate is usually more useful than spending time refining assumptions that will not change the design.

Speakers and Sources

• Speaker: One unnamed narrator; no guests or other speakers are featured.
• Source: ByteByteGo video. The Twitter figures in the examples are explicitly presented as made-up estimates, not official data.