How Back of the Envelope helps with System Design?

The back of the envelope generally means a rough estimate you make to plan your things.

Why do we need it?

We usually start with designing the system before analyzing it. Do you think it is the right way to start with?

Without any rough estimation of your requirement, how will you decide whether you require caching? Which database is suitable? How many servers?

Should you load things sequentially? Parallelly?

Can you identify the cost and decide if it’s worth going ahead?

How??

For many such decisions, we must do the back of the envelope ✉️

It helps us check trade-offs between different designs

We should know these numbers to start with the analysis. You will realize why we need these numbers soon.

Scale

We need to determine the scale of the system you are designing, such as the number of users or requests per second. This can help you estimate the size of the infrastructure required.

What parameter do you need to determine that?

User base: Determine the number of users or customers that the system is expected to serve.

Query per second: No. of query hits per second.

Seconds in a day = 24days * 60 min * 60 sec = 86400 seconds = ~1⁰⁵ seconds

Consider there are 100 million Daily active users (DAU)

Assume a user hits 5 queries a day

QPS = 5 * 100 million / 1⁰⁵ sec = 5000 QPS

This will help you analyze the number of servers required on basis of server capacity.

Like if a server can handle 2000QPS, you may require 3 servers.

Transaction per second (TPS)

No. of transactions per second, a database can handle a few thousand TPS

Consider a hotel reservation company

Daily reservations: 1,000,000

Reservation per second = 100,000 / 1⁰⁵ second in a day = 10 reservations = 10 Transaction per second (TPS)

It is not a big deal for a database which gives us an idea that we need not focus on aiming for high throughput in our design ahead.

If it would have been more than capable of a database like 50,000 TPS, you might need to think to work on different approaches to tackle this as a single node of the database won't help here

We can also calculate QPS from TPS by assuming 10% of the user only reaches the next step

There are three steps

View Hotel
Order booking page
Reserve rooms

We know the query per second (QPS) of the reserve rooms step is 10, as discussed above. So, with the assumption, the QPS of the order booking page would be 10 * 10 = 100 QPS.

Similarly, for the view hotel can be 100 * 10 QPS = 1000 QPS

This gives us a rough estimate of the traffic to our system and accordingly can work on scalability.

Performance

We need to define the expected performance of the system.

This can be defined by parameters such as response times, throughput, and availability. This can help you estimate the number of servers required and their specifications.

What are the required response times for the system? What is the maximum load it will need to handle? What are the expected throughput and latency requirements?

A read/write ratio compares the percentage of read operations to write operations between the server and its storage devices. Considering the read-write ratio of 10:1, reading is 10 times more common than writing. Here we can add more slaves to handle high reading, thus increasing performance.

Many more factors affect performance like

The service in case has 100 QPS hits; each request returns 30 pages of content. How many hard drives would you need to keep request latency low?

Assuming a 0.5 Gbps link per machine, if we want to crawl 50 TB of websites every day, how many servers would a system need?

It is necessary to analyze how many servers a system would need to support the traffic at the required performance.

Storage

We also need to estimate the amount of storage required for the system based on the size of the data generated, retention periods, and growth rates.

Let’s calculate data storage for

1 billion users,

For 1 year,

The average size of an object = 50KB

Average no. of 40 objects sent by a person in a single day

How to calculate storage?

1 billion * (365 days) * (50 KB) * ( 40 emails/day)
= 1⁰⁹ * (365 days) * (50 KB) * ( 40 emails/day)
= 1⁰⁹ users * 14600 emails per year per user* 50 KB
= 146 * 1⁰¹¹ emails per year * 50 KB = 730 * 1⁰¹² KB of storage per year
= 730 PB of storage per year

Now accordingly we can decide how much capacity database to choose.

Cost

Estimating the cost of building and maintaining the system is also an important factor.

Consider a video streaming service. TB of videos are uploaded daily and since CDN helps with the performance we plan to analyze the cost of it.

Assume the average cost of CDN per GB is $0.02.

So the total cost will be $0.02 * 75,000 TB = $150,000 per day.

which seems to be quite costly. What to do now?

This way, we can analyze the cost and decide on approaches.

Security

What are the security requirements for the system? What measures will be taken to ensure the security and privacy of the data?

Timeframe

What is the proposed timeframe for development, testing, and deployment? What are the milestones and deliverables for each phase?

There are 10 programmers and 100 tasks. How many more weeks until a possible launch?

Functionality

What functions does the system need to perform? What features should it have?

Reference:

Back of the Envelope Calculation for System Design Interviews | Codementor

System Design Interview — An Insider’s Guide by Alex Xu