Back-of-the-envelope estimation in HLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to estimate the number of requests per second for a system.

HLD

requests_per_second = total_requests [1] total_seconds

Drag options to blanks, or click blank then click option'

A+

B*

C-

D/

Attempts:

3 left

💡 Hint

Common Mistakes

Using multiplication instead of division.

Adding or subtracting instead of dividing.

To find requests per second, divide total requests by total seconds.

2fill in blank

medium

Complete the code to estimate the total storage needed for user data.

HLD

total_storage_gb = number_of_users [1] average_data_per_user_gb

Drag options to blanks, or click blank then click option'

A-

B+

C*

D/

Attempts:

3 left

💡 Hint

Common Mistakes

Dividing instead of multiplying.

Adding instead of multiplying.

Total storage is the number of users multiplied by average data per user.

3fill in blank

hard

Fix the error in the code estimating peak traffic per hour.

HLD

peak_traffic_per_hour = average_traffic_per_minute [1] 60

Drag options to blanks, or click blank then click option'

A*

B/

C+

D-

Attempts:

3 left

💡 Hint

Common Mistakes

Dividing by 60 instead of multiplying.

Adding or subtracting 60.

To get hourly traffic from per minute, multiply by 60 minutes.

4fill in blank

hard

Fill both blanks to estimate total bandwidth needed for video streaming.

HLD

total_bandwidth_mbps = number_of_streams [1] average_bandwidth_per_stream_mbps [2] overhead_factor

Drag options to blanks, or click blank then click option'

A*

B+

D-

Attempts:

3 left

💡 Hint

Common Mistakes

Adding instead of multiplying.

Subtracting overhead factor.

Total bandwidth is number of streams times average bandwidth per stream, multiplied by overhead factor.

5fill in blank

hard

Fill all three blanks to estimate the number of servers needed.

HLD

servers_needed = (total_requests_per_second [1] requests_per_server_capacity) [2] safety_margin [3] 1

Drag options to blanks, or click blank then click option'

A/

B*

C+

D-

Attempts:

3 left

💡 Hint

Common Mistakes

Multiplying instead of dividing for base servers.

Adding safety margin instead of multiplying.

Not adding buffer server.

Divide total requests by server capacity, multiply by safety margin, then add 1 for buffer.

Practice

1. What is the main purpose of back-of-the-envelope estimation in system design?

easy

A. To quickly estimate system requirements using simple calculations

B. To write detailed code for the system

C. To create a full architecture diagram

D. To perform in-depth performance testing

Solution

1. Step 1: Understand the goal of back-of-the-envelope estimation

   This method is used to quickly guess system needs without detailed work.

2. Step 2: Compare options to the goal

   Only To quickly estimate system requirements using simple calculations matches the quick estimation purpose; others are detailed tasks.

3. Final Answer:

   To quickly estimate system requirements using simple calculations -> Option A

4. Quick Check:

   Quick estimation = To quickly estimate system requirements using simple calculations [OK]

Hint: Focus on quick, simple calculations for early guesses [OK]

Common Mistakes:

• Confusing estimation with detailed design
• Thinking it involves coding or testing
• Assuming it requires full diagrams

2. Which of the following is the correct way to start a back-of-the-envelope estimation for a web service's daily traffic?

easy

A. Calculate exact user behavior with detailed logs

B. Estimate average users per hour and multiply by 24

C. Design the database schema first

D. Write the full API specification

Solution

1. Step 1: Identify the starting point for traffic estimation

   Back-of-the-envelope estimation uses simple averages, not detailed data.

2. Step 2: Evaluate options for simplicity and relevance

   Estimate average users per hour and multiply by 24 uses average users per hour times 24 hours, a simple and effective start.

3. Final Answer:

   Estimate average users per hour and multiply by 24 -> Option B

4. Quick Check:

   Simple average x time = Estimate average users per hour and multiply by 24 [OK]

Hint: Use simple averages and multiply by time units [OK]

Common Mistakes:

• Starting with detailed logs instead of rough estimates
• Jumping to design before estimating traffic
• Confusing estimation with specification writing

3. You estimate a system will have 10,000 users daily, each making 5 requests on average. What is the total number of requests per day?

medium

A. 100,000 requests

B. 2,000 requests

C. 15,000 requests

D. 50,000 requests

Solution

1. Step 1: Multiply users by requests per user

   10,000 users x 5 requests each = 50,000 requests.

2. Step 2: Confirm total requests per day

   The total is simply the product of users and requests per user.

3. Final Answer:

   50,000 requests -> Option D

4. Quick Check:

   Users x requests = 50,000 [OK]

Hint: Multiply users by average requests per user [OK]

Common Mistakes:

• Adding instead of multiplying
• Mixing up users and requests
• Choosing an option too large or too small

4. A designer estimated 1 million requests per day but forgot to consider peak hour traffic. What is the likely problem with this estimation?

medium

A. Ignoring average request size affecting storage needs

B. Overestimating total daily traffic causing wasted resources

C. Underestimating peak load leading to potential system overload

D. Not including user authentication time

Solution

1. Step 1: Understand the impact of ignoring peak traffic

   Peak traffic is often much higher than average, so ignoring it underestimates load.

2. Step 2: Identify the consequence of underestimation

   System may overload during peak times if capacity is based on average only.

3. Final Answer:

   Underestimating peak load leading to potential system overload -> Option C

4. Quick Check:

   Ignoring peak = underestimation risk [OK]

Hint: Always consider peak, not just average, traffic [OK]

Common Mistakes:

• Assuming daily average covers peak needs
• Confusing storage with traffic load
• Focusing on unrelated factors like authentication time

5. You need to estimate the storage required for a photo-sharing app. Each photo is 3MB, and you expect 500,000 uploads per month. What is the approximate monthly storage needed?

hard

A. 1.5 TB

B. 150 GB

C. 15 GB

D. 1.5 GB

Solution

1. Step 1: Calculate total storage in MB

   500,000 photos x 3 MB each = 1,500,000 MB.

2. Step 2: Convert MB to TB

   1,500,000 MB ÷ 1024 ≈ 1465 GB ÷ 1024 ≈ 1.43 TB, approximately 1.5 TB.

3. Final Answer:

   1.5 TB -> Option A

4. Quick Check:

   Uploads x size ≈ 1.5 TB [OK]

Hint: Multiply count by size, then convert units [OK]

Common Mistakes:

• Forgetting to convert MB to GB
• Mixing up MB and GB units
• Using wrong multiplication factors