Premium Video

This video is available to premium subscribers only

Unlock Full Access

In this chapter, we'll learn how to do back-of-the-envelope or capacity estimations in system design interviews. We'll cover the key numbers worth remembering, and see how to use these estimates to make better design decisions.

In a system design interview, estimation isn't about testing your math skills. It's about helping you make better design decisions.

For example, estimates can help you determine:

But this doesn't mean you need to estimate everything.

In a ticket booking system, for example, total storage is unlikely to be a major concern, so calculating it in detail may not add much value.

On the other hand, for a video platform like YouTube, storage and bandwidth estimates can have a significant impact on your architecture. They help you decide how to store large video files, distribute content, and handle traffic at scale.

So before doing any calculation, ask yourself:

"What design decision will this estimate help me make?"

If you don't have a clear answer, you can probably skip it and come back to it later if needed.

Most calculations in system design interviews involve large numbers, so it's useful to be comfortable working with powers of ten.

You might also come across terms like kibibyte and mebibyte. These are binary units based on powers of 2 rather than powers of 10.

These units are commonly used when measuring computer memory and storage. However, for rough estimates in interviews, we can use powers of ten to keep the calculations simple.

For example, suppose we have 1 billion records, each taking 1 kilobyte:

Instead of multiplying large numbers directly, we can multiply the leading numbers, add their exponents, and convert the result back into a familiar unit. This makes calculations faster and reduces the chances of making mistakes.

Next, let's look at how to convert daily traffic into requests per second, since that's how we usually discuss system capacity.

There are 86,400 seconds in a day, but for quick estimates, we can round that to 100,000, or 10^5. This makes the calculations much easier.

A few conversions are worth remembering:

Both approaches are fine for rough estimates, as long as you're consistent.

You can also round a year to 400 days when estimating annual storage, which simplifies the math and gives you a little extra margin.

Latency numbers help you understand where time is spent when processing a request. You don't need to memorize exact values. What's more important is knowing the approximate latency of different operations and how they compare.

Each step down this ladder is roughly 5 to 1,000 times slower than the one before it:

So what do these numbers tell us when designing a system?

To estimate storage requirements, we first need to know roughly how much space each record takes. Let's start with the sizes of some common data types.

Using these numbers, we can estimate the size of a typical record. For example, a social media post containing an ID, an author ID, a timestamp, and up to 280 characters of text would take a few hundred bytes. We can round that to 1 kilobyte to account for additional metadata and storage overhead.

Media files, however, are much larger and often account for most of the storage.

And since video platforms typically store multiple resolutions of each video, the actual storage requirement can be significantly higher.

Next, let's look at the approximate capacity of common components. Keep in mind that actual performance depends on hardware, workload, and data size, so these numbers are just rough guidelines.

A few notes on these numbers:

These numbers help you decide when a single machine is enough and when you need to scale horizontally.

For example, if your system handles 500 database writes per second, a single primary database will likely be sufficient. But if you're expecting 500,000 writes per second, you'll probably need to distribute the workload across multiple machines using sharding, a write-optimized database, or a combination of both.

Now that we have some reference numbers, let's put them into practice. We'll use a social media platform like Twitter as an example and estimate request rates, storage, bandwidth, cache memory, and the number of servers.

A good starting point is the number of daily active users. Let's assume we have 200 million.

Next, we need to estimate how often users perform different actions. Suppose each user creates an average of 2 posts and views their feed 50 times per day.

But these are just average numbers. In practice, traffic isn't evenly distributed throughout the day. It tends to peak during busy hours and around major events.

A common assumption is that peak traffic is 2 to 3 times the average. So in our example, we might expect:

Finally, notice that our feed request rate is about 25 times the post creation rate. This tells us that the system is heavily read-oriented, so we should consider optimizations like precomputing feeds and caching frequently accessed data.

Storage estimation follows a similar approach. We take the number of new records created each day, multiply it by the size of each record, and then by how long we need to store them.

Using our social media example:

We also need to consider replication. Production databases typically maintain multiple copies of data to protect against failures. With 3 copies, our 800 terabytes of post data becomes roughly 2.4 petabytes of physical storage.

But that's just the text data. Let's also account for images. Suppose 10 percent of posts contain an image, with an average size of 500 kilobytes.

Now, what do these estimates tell us about the design?

Next, let's estimate bandwidth, which tells us how much data enters and leaves the system every second. Since images are much larger than text, we'll focus on image traffic for this calculation.

For incoming traffic, we can divide the total daily upload volume by the number of seconds in a day:

Outgoing traffic is usually much higher because the same image can be viewed many times. Suppose each feed request loads 10 images, and our system handles 100,000 feed requests per second. Even with compressed images of just 50 kilobytes each:

That's far more than a single server's network interface can typically handle.

This is where a CDN becomes useful. Instead of serving every image directly from our servers, we can cache images at edge locations closer to users. This distributes the bandwidth across the CDN's network and significantly reduces the traffic reaching our origin servers.

Next, let's estimate how much memory we need for caching frequently accessed data in an in-memory store like Redis.

In most systems, data access isn't evenly distributed. A relatively small portion of the data often receives most of the traffic. In our social media example, viral posts might get far more views than regular posts. As a rough starting point, we could assume that caching the most frequently accessed 20 percent of the data would cover a large share of reads.

Now, let's estimate the memory needed to cache precomputed feeds. Suppose we cache a feed for every daily active user, containing the IDs of their 500 most recent posts.

That's too much for a typical single Redis instance, so we'd need to distribute the cache across multiple nodes. If each node has about 100 gigabytes of usable memory, we'd need roughly 10 to 15 primary nodes, along with replicas for availability.

But caching every user's feed may not be necessary. To reduce memory usage, we could cache feeds only for recently active users or store just 200 post IDs instead of 500.

Finally, let's estimate how many application servers we need to handle the expected traffic.

The calculation is straightforward. We divide the peak requests per second by the number of requests a single server can handle.

However, we don't want to run every server at full capacity. We need some extra capacity to handle unexpected traffic spikes and server failures. Adding 30 to 50 percent headroom brings our estimate to around 80 to 90 servers.

We'd also use a load balancer to distribute incoming requests across these servers.

In cloud-based systems, we can use auto-scaling to automatically add more servers when traffic increases and remove them when traffic drops. This helps us handle peak demand without paying for unnecessary capacity during quieter periods.

Here's a summary of the estimates and the design decisions they point to:

How you present your estimates is almost as important as the calculations themselves.

Make your assumptions clear

For example, you might say:

"I'll assume 200 million daily active users, with each user creating 2 posts per day, and each post taking about 1 kilobyte of storage."

This gives the interviewer a chance to correct your assumptions before you start calculating.

Don't spend too much time on estimation

In most system design interviews, a few minutes should be enough. Focus on the numbers that actually influence your architecture, and skip calculations that won't change your design.

You don't want to waste valuable interview time doing unnecessary math, especially when you're working without a calculator.

Let's look at a few common mistakes to avoid when estimating system capacity.

1. Confusing bits and bytes

Network bandwidth is usually measured in bits per second, while storage is measured in bytes. Mixing them up can throw off your calculations by a factor of 8.

2. Designing only for average traffic

In practice, traffic varies throughout the day, and the system needs enough capacity to handle peak load without becoming overloaded.

3. Forgetting replication and storage overhead

If you're storing 3 copies of your data, you'll need 3 times the raw storage. Indexes, metadata, and other overhead can increase that further.

4. Being unnecessarily precise

Saying your system handles 4,629.6 requests per second doesn't add much value when the assumptions themselves are approximate. Rounding to one or two significant digits is usually enough.

5. Estimating things that won't influence your design

If a calculation doesn't help you make an architectural decision, it's probably better to skip it and focus on the more important parts of the interview.

Here are the key numbers we've covered:

With these numbers, you can quickly estimate request rates, storage requirements, bandwidth, cache memory, and server capacity. Just remember to account for peak traffic, replication, and other overhead where necessary.

Most importantly, don't estimate numbers just for the sake of it. Focus on the estimates that help you make better design decisions, and explain how those numbers influence your architecture.