Back-Of-The-Envelope Estimation / Capacity Planning

Summary

This video script introduces back-of-the-envelope math as a valuable tool for system design, emphasizing its utility in quickly estimating and sanity-checking designs without the need for extreme precision. It explains how to estimate requests per second and queries per second using metrics like DAU and scaling factors. The script provides an example of calculating Twitter's peak tweet creation rate and offers tips for simplifying calculations with scientific notation. It also demonstrates how to estimate storage requirements for multimedia files in tweets, illustrating the process with made-up numbers. The video encourages a practical approach to system design, focusing on order-of-magnitude accuracy rather than exact figures.

Takeaways

• 📝 Back-of-the-envelope math is a valuable tool for system design, used to quickly sanity-check a design without needing absolute accuracy.
• 🔢 It's sufficient to be within an order of magnitude or two of the actual numbers when using this method for preliminary calculations.
• 💡 This math helps in understanding the scale of infrastructure needed, like the number of web servers or the necessity of database sharding or caching.
• ⚙️ The most common metric to estimate is requests per second at the service level or queries per second at the database level.
• 👥 Daily Active Users (DAU) is a key input, often estimated as a percentage of Monthly Active Users (MAU) if only MAU is available.
• 📈 Usage per DAU must be estimated, taking into account that not all active users will engage in the same way with the service.
• 📊 A scaling factor is necessary to account for peak usage times, which can be significantly higher than average traffic.
• ✂️ Simplifying calculations involves converting large numbers into scientific notation to minimize errors and facilitate quick mental math.
• 🧠 Memorizing certain large number conversions, like 10^12 representing a trillion or a terabyte, can expedite the back-of-the-envelope math process.
• 🗃️ Storage requirements can be estimated by calculating the volume of data generated, the proportion containing multimedia, average file sizes, replication factors, and retention periods.
• 📚 The script emphasizes that precision is less critical than being within an order of magnitude, which is typically adequate for design validation.

Q & A

What is back-of-the-envelope math used for in system design?

Back-of-the-envelope math is used for quickly sanity-checking a design in system design, where absolute accuracy is not as important as getting within an order of magnitude or two of the actual numbers.

Why is absolute accuracy not crucial when using back-of-the-envelope math?

Absolute accuracy is not crucial because it's usually sufficient to be within an order of magnitude or two of the actual numbers to make informed decisions about system design.

What are the two key insights gained from the example of web service needing to handle 1M requests per second?

The two key insights are that a cluster of web servers with a load balancer is needed, and approximately 100 web servers would be required to handle the load.

Why might a single database server be sufficient to handle the load for a while without sharding or caching?

A single database server might be sufficient if the math shows that it only needs to handle a few queries per second at peak, indicating that it can manage the load without additional optimizations for a while.

What is the most useful metric to estimate when using back-of-the-envelope math for system design?

The most useful metric to estimate is requests per second at the service level or queries per second at the database level.

How is Daily Active Users (DAU) typically obtained and related to Monthly Active Users (MAU)?

DAU should be easy to obtain, but if only MAU is available, DAU is estimated as a percentage of MAU.

What is the significance of the usage per DAU estimate in system design calculations?

The usage per DAU estimate helps determine the percentage of active users who will interact with the service, which is crucial for calculating the load on the system.

Can you explain the concept of a scaling factor in the context of back-of-the-envelope math?

A scaling factor is used to estimate how much higher the traffic would peak compared to the average, reflecting the potential requests-per-second peak where the design could break.

How is the example of estimating Tweets created per second on Twitter calculated?

The calculation involves multiplying the number of DAU by the average tweets per DAU, applying a scaling factor for peak times, and then dividing by the number of seconds in a day.

What technique is suggested for simplifying calculations in back-of-the-envelope math?

Converting all big numbers to scientific notation is suggested, as it simplifies multiplication to addition and division to subtraction.

Why is it important to memorize certain conversions when performing back-of-the-envelope math?

Memorizing certain conversions, like 10^12 being a trillion or a terabyte, helps in quickly converting and simplifying large numbers during calculations.

How does the example calculate the required storage for multimedia files in tweets?

The calculation involves estimating the percentage of tweets containing multimedia, the average size of those files, the replication factor, the duration of storage, and then applying the appropriate mathematical operations.

What is the conclusion about back-of-the-envelope math in system design?

Back-of-the-envelope math is a very useful tool in system design; it's important not to over-index on precision, as being within an order of magnitude is usually enough to inform and validate design decisions.