Advanced
Estimation Language
#system-design
#calculations
Back-of-Envelope Estimates
6 exercises — narrate DAU, storage, bandwidth, and growth calculations for system design discussions using correct order-of-magnitude language.
0 / 26 completed
1 / 26
A system design interviewer asks: "How many requests per second does Twitter handle?" What is the correct approach for a back-of-envelope estimate?
Option C — a narrated, step-by-step estimation chain with explicit assumptions and a peak multiplier.
Back-of-envelope estimation structure:
Key vocabulary:
• "Let's say / let's assume" — opens an assumption explicitly
• "roughly / approximately / around" — signals estimated values
• "on average" — distinguishes average from peak
• "at peak / peak traffic" — addresses worst-case load
• "Divide by 86,400 seconds" — showing the calculation builds confidence
86,400 seconds in a day = memorise this for system design. Useful multiples:
• 1 day = 86,400 s ≈ 10⁵ s
• 1 month = ~2.6M s ≈ 3×10⁶ s
• 1 year = ~31.5M s ≈ 3×10⁷ s
Why estimation fluency matters:
In system design discussions, the calculation itself is less important than narrating your reasoning clearly — interviewers and colleagues want to see that you can reason under uncertainty.
Back-of-envelope estimation structure:
1. Base number: "let's say [X]M monthly active users" 2. Daily active rate: "approximately 20% are active daily → [Y]M DAU" 3. Per-user behavior: "each user makes ~10 requests/day" 4. Total per day: "[Y]M × 10 = [Z]M requests/day" 5. Per second: "divide by 86,400 seconds → [N] rps" 6. Peak adjustment: "peak traffic is ~3–5× average → [P] rps at peak"
Key vocabulary:
• "Let's say / let's assume" — opens an assumption explicitly
• "roughly / approximately / around" — signals estimated values
• "on average" — distinguishes average from peak
• "at peak / peak traffic" — addresses worst-case load
• "Divide by 86,400 seconds" — showing the calculation builds confidence
86,400 seconds in a day = memorise this for system design. Useful multiples:
• 1 day = 86,400 s ≈ 10⁵ s
• 1 month = ~2.6M s ≈ 3×10⁶ s
• 1 year = ~31.5M s ≈ 3×10⁷ s
Why estimation fluency matters:
In system design discussions, the calculation itself is less important than narrating your reasoning clearly — interviewers and colleagues want to see that you can reason under uncertainty.
2 / 26
You are estimating storage for a photo-sharing app. Which narration is correct?
Option B — explicit per-unit arithmetic, correct unit labels, and order-of-magnitude extrapolation.
Per-unit storage estimation structure:
Common storage unit conversions to know:
• 1 KB = 10³ bytes
• 1 MB = 10⁶ bytes
• 1 GB = 10⁹ bytes
• 1 TB = 10¹² bytes
• 1 PB = 10¹⁵ bytes
• 1 EB = 10¹⁸ bytes
Narration patterns:
• "that's [X] × [Y] = [Z]" — narrate the multiplication
• "which gives us roughly" — introduces a rounded result
• "we're talking about [order-of-magnitude]" — e.g., "exabyte-scale"
• "over 5 years at 10× growth" — extrapolation frame
• "that's on the order of" — signals approximate
Replication factor:
In practice, multiply raw storage by the replication factor (typically 3× for distributed storage like HDFS, S3). Always mention this: "Raw storage × 3 for replication = actual storage required."
Per-unit storage estimation structure:
[Number of users] × [uploads per user per day] × [size per item] = [total storage per day] [Daily] × [days per year] × [years] × [growth factor] = [total storage over system lifetime]
Common storage unit conversions to know:
• 1 KB = 10³ bytes
• 1 MB = 10⁶ bytes
• 1 GB = 10⁹ bytes
• 1 TB = 10¹² bytes
• 1 PB = 10¹⁵ bytes
• 1 EB = 10¹⁸ bytes
Narration patterns:
• "that's [X] × [Y] = [Z]" — narrate the multiplication
• "which gives us roughly" — introduces a rounded result
• "we're talking about [order-of-magnitude]" — e.g., "exabyte-scale"
• "over 5 years at 10× growth" — extrapolation frame
• "that's on the order of" — signals approximate
Replication factor:
In practice, multiply raw storage by the replication factor (typically 3× for distributed storage like HDFS, S3). Always mention this: "Raw storage × 3 for replication = actual storage required."
3 / 26
How do you correctly express an order-of-magnitude result in a back-of-envelope context?
Option C — gives the order-of-magnitude result, names the scale, and draws a practical infrastructure conclusion.
Order-of-magnitude vocabulary:
• "We're in the ballpark of" — conversational OM phrase
• "on the order of" — more formal
• "roughly" — signals approximation
• "in the [X]-scale" — e.g., "terabyte-scale", "petabyte-scale", "gigabyte-scale"
• "an order of magnitude [larger/smaller] than" — comparing two estimates; ×10 difference
Order of magnitude examples:
• "1 billion (10⁹) is an order of magnitude larger than 100 million (10⁸)"
• "We're in the terabyte range, not the gigabyte range"
• "This is exabyte-scale — beyond what a single cluster can hold"
Drawing a conclusion from the estimate (important!):
The best back-of-envelope answers don't just compute a number — they map it to a practical consequence:
• "petabyte-scale → distributed object storage (S3, GCS)"
• "7,000 rps → need horizontal scaling; single server will not handle this"
• "10TB/day → streaming ingest pipeline (Kafka), not synchronous writes"
• "200ms per request at P99 → need a CDN or edge caching layer"
This is the skill that distinguishes system design experts: the estimate leads to a concrete architectural decision.
Order-of-magnitude vocabulary:
• "We're in the ballpark of" — conversational OM phrase
• "on the order of" — more formal
• "roughly" — signals approximation
• "in the [X]-scale" — e.g., "terabyte-scale", "petabyte-scale", "gigabyte-scale"
• "an order of magnitude [larger/smaller] than" — comparing two estimates; ×10 difference
Order of magnitude examples:
• "1 billion (10⁹) is an order of magnitude larger than 100 million (10⁸)"
• "We're in the terabyte range, not the gigabyte range"
• "This is exabyte-scale — beyond what a single cluster can hold"
Drawing a conclusion from the estimate (important!):
The best back-of-envelope answers don't just compute a number — they map it to a practical consequence:
• "petabyte-scale → distributed object storage (S3, GCS)"
• "7,000 rps → need horizontal scaling; single server will not handle this"
• "10TB/day → streaming ingest pipeline (Kafka), not synchronous writes"
• "200ms per request at P99 → need a CDN or edge caching layer"
This is the skill that distinguishes system design experts: the estimate leads to a concrete architectural decision.
4 / 26
How do you correctly use a rounding assumption in a back-of-envelope calculation?
Option C — uses a known rounding (86,400 → 10⁵), states the rounding direction, and notes its effect on the estimate.
Rounding language in estimation:
• "rounding up to be conservative" — standard phrase; conservative = worst-case; used when you want to provision more, not less
• "rounding down to be optimistic" — rare in infrastructure; used when making a business case for cost
• "that's a safe upper bound" — after rounding up
• "to keep the arithmetic clean, I'll use [rounded value]" — explains the rounding choice
• "that's close enough for a back-of-envelope" — explicitly disclaiming precision
Standard rounding values to know:
• 86,400 → 10⁵ (100K)
• 30 days/month → use 30 or 31
• 365 days → use 400 for quick arithmetic; use 365 for accuracy
• 1M monthly active users → "let's call it 1M" is fine
• Latency: 1ms (in-memory), 100μs (L3 cache), 10μs (L2), 100ns (L1), 1ns (registers)
Conservative vs. optimistic matters:
When provisioning infrastructure, always round up — you'd rather over-provision than have an outage. When estimating costs for a budget, being clear about which direction you're rounding is critical to avoid surprises.
Rounding language in estimation:
• "rounding up to be conservative" — standard phrase; conservative = worst-case; used when you want to provision more, not less
• "rounding down to be optimistic" — rare in infrastructure; used when making a business case for cost
• "that's a safe upper bound" — after rounding up
• "to keep the arithmetic clean, I'll use [rounded value]" — explains the rounding choice
• "that's close enough for a back-of-envelope" — explicitly disclaiming precision
Standard rounding values to know:
• 86,400 → 10⁵ (100K)
• 30 days/month → use 30 or 31
• 365 days → use 400 for quick arithmetic; use 365 for accuracy
• 1M monthly active users → "let's call it 1M" is fine
• Latency: 1ms (in-memory), 100μs (L3 cache), 10μs (L2), 100ns (L1), 1ns (registers)
Conservative vs. optimistic matters:
When provisioning infrastructure, always round up — you'd rather over-provision than have an outage. When estimating costs for a budget, being clear about which direction you're rounding is critical to avoid surprises.
5 / 26
You are estimating bandwidth requirements. Which narration is correct?
Option C — complete, narrated bandwidth calculation with concurrent users, per-user rate, aggregation, peak multiplier, and an architectural conclusion.
Bandwidth estimation structure:
Bandwidth vocabulary:
• "concurrent users" — users active simultaneously (not total users)
• "egress bandwidth" — data flowing OUT of your infrastructure (what you pay for)
• "ingress bandwidth" — data flowing INTO your infrastructure
• "at peak" — maximum load condition
• "CDN" (Content Delivery Network) — distributes bandwidth load globally
• "throughput" — data transferred per unit of time
Unit conversions:
• 1 Gbps = 1,000 Mbps = 10⁹ bits/s
• 1 Gbps ≈ 125 MB/s (divide by 8 for bytes)
• 1 MB ≈ 8 Mbits
Estimate steps when given bandwidth questions:
1. Start with concurrent users (not total users)
2. Establish per-user rate: streaming (1–8 Mbps), web page load (~2 Mbps burst), API calls (~1 Kbps)
3. Multiply: concurrent × per-user = total
4. Apply peak multiplier (2–5×)
5. Compare to single-server limits (~10 Gbps typical datacenter NIC)
6. Draw the architectural conclusion
Bandwidth estimation structure:
[Concurrent users] × [per-user bandwidth] = [total bandwidth] × [peak multiplier] = [peak bandwidth] → [architectural consequence]
Bandwidth vocabulary:
• "concurrent users" — users active simultaneously (not total users)
• "egress bandwidth" — data flowing OUT of your infrastructure (what you pay for)
• "ingress bandwidth" — data flowing INTO your infrastructure
• "at peak" — maximum load condition
• "CDN" (Content Delivery Network) — distributes bandwidth load globally
• "throughput" — data transferred per unit of time
Unit conversions:
• 1 Gbps = 1,000 Mbps = 10⁹ bits/s
• 1 Gbps ≈ 125 MB/s (divide by 8 for bytes)
• 1 MB ≈ 8 Mbits
Estimate steps when given bandwidth questions:
1. Start with concurrent users (not total users)
2. Establish per-user rate: streaming (1–8 Mbps), web page load (~2 Mbps burst), API calls (~1 Kbps)
3. Multiply: concurrent × per-user = total
4. Apply peak multiplier (2–5×)
5. Compare to single-server limits (~10 Gbps typical datacenter NIC)
6. Draw the architectural conclusion
6 / 26
How do you express a growth extrapolation in a back-of-envelope estimate?
Option B — explicit compounding growth calculation narrated year-by-year with a planning conclusion.
Growth extrapolation structure:
Growth rate phrases:
• "growing at 100% year-over-year" — doubling annually
• "~50% YoY growth" — 1.5× per year
• "10× growth over 3 years" — total multiplier
• "at this rate, we're looking at…" — extrapolation opener
• "assuming linear / exponential growth" — model choice
Common growth multipliers:
• 100% YoY = 2× per year = 8× in 3 years = ~32× in 5 years
• 50% YoY = 1.5× per year = ~3.4× in 3 years = ~7.6× in 5 years
• 20% YoY = 1.2× per year = ~1.7× in 3 years
Planning conclusion language:
• "I'd design for 10× current capacity"
• "We need an architecture that can scale horizontally without a rewrite"
• "At 8× we'd be hitting our current database limits — plan for sharding at ~4× to give lead time"
• "Build for 5× now, re-evaluate at 3× with a clear migration path"
In real design conversations, the specific numbers matter less than demonstrating you can reason about growth systematically and draw concrete planning conclusions.
Growth extrapolation structure:
Start: [current metric] growing at [rate] year-over-year. Year 1: [×2 from start] Year 2: [×4 from start] Year 3: [×8 from start] → "plan for [X×] today's baseline"
Growth rate phrases:
• "growing at 100% year-over-year" — doubling annually
• "~50% YoY growth" — 1.5× per year
• "10× growth over 3 years" — total multiplier
• "at this rate, we're looking at…" — extrapolation opener
• "assuming linear / exponential growth" — model choice
Common growth multipliers:
• 100% YoY = 2× per year = 8× in 3 years = ~32× in 5 years
• 50% YoY = 1.5× per year = ~3.4× in 3 years = ~7.6× in 5 years
• 20% YoY = 1.2× per year = ~1.7× in 3 years
Planning conclusion language:
• "I'd design for 10× current capacity"
• "We need an architecture that can scale horizontally without a rewrite"
• "At 8× we'd be hitting our current database limits — plan for sharding at ~4× to give lead time"
• "Build for 5× now, re-evaluate at 3× with a clear migration path"
In real design conversations, the specific numbers matter less than demonstrating you can reason about growth systematically and draw concrete planning conclusions.
7 / 26
Reviewer: 'I'm seeing a potential bottleneck here. The team estimates 10,000 daily active users (DAU) generating an average of 5 events per user per day. If we're using a REST API with a 20ms latency overhead and assuming synchronous processing for each event, what's a reasonable back-of-envelope estimate for the total system latency? Let's keep it simple.'This question tests understanding of applying basic estimation principles to a real-world scenario. The initial calculation is flawed because it doesn't consider potential bottlenecks like rate limits or increased latency during peak periods. A back-of-envelope estimate should acknowledge these factors and provide a range rather than a single, overly optimistic value. Remember, the goal isn't precision; it's identifying potential issues quickly.
8 / 26
Senior Dev: 'Okay team, we're migrating to this new microservice. Initial estimates put the number of requests per second at around 500. But I'm seeing some concerns about scaling. Let's run a quick back-of-envelope calculation to see if that's feasible. Assume each request takes roughly 10ms of processing time and we have 10 instances running in parallel. What's the best way to frame the result for discussion?', This question tests understanding of communicating results from back-of-envelope estimates in a professional setting. The key here isn't just the calculation itself (which is simplified), but how to frame the result and acknowledge its limitations. Options A and D are overly confident and fail to account for potential issues; option B provides an unrealistic target, while option C accurately reflects the nature of a preliminary estimate—emphasizing the need for further investigation—making it the most appropriate response.
9 / 26
During a sprint review, the frontend team presents their redesigned user profile page. They've estimated it will require 20KB of storage per profile and expect 1 million users in the next year. The team wants to discuss potential infrastructure costs. Which statement best describes how you would frame a back-of-envelope estimate for this scenario?
The correct answer (option 2) acknowledges the initial calculation but immediately adds the crucial element of considering ongoing costs and growth. Options A and B present overly simplistic or potentially disastrous calculations. Option D is misleading as it relies on a flawed assumption about current usage being representative of future needs.
10 / 26
During a standup meeting, Sarah (Backend) says: 'We're building a new recommendation engine. We're processing about 500,000 user interactions per hour and each interaction takes roughly 2ms to process on our current infrastructure. I'm thinking we need to scale up the number of servers.' John (Frontend), immediately responds with: 'That sounds like a lot! What's your back-of-envelope estimate for the overall system throughput?' Which statement best captures John's request for Sarah to provide a useful back-of-envelope estimate?
John is asking for a high-level, rapid estimation – a 'back-of-envelope' calculation. Option A demands precision far beyond what's feasible initially; option B focuses solely on an hourly metric without considering the processing time. Options C and D are too vague and don't directly relate to the core concept of estimating system throughput based on key inputs like interaction rate and latency. The correct answer, focusing on peak load, aligns with the purpose of a back-of-envelope estimate – a quick, pragmatic approach.
11 / 26
During a sprint planning session, the team is discussing the performance of a new feature that generates daily reports. The lead engineer states: 'We're generating approximately 50,000 reports per day, each containing roughly 1KB of data. We're using a simple database query to retrieve this information. Let's quickly estimate the server load to ensure we have sufficient resources.' Which phrasing best describes the situation and the engineer's need for a back-of-envelope estimate?
The engineer isn't looking for a perfect prediction; they need a preliminary assessment to gauge whether their current setup can handle the load. A back-of-envelope estimate allows them to quickly identify potential bottlenecks and determine if scaling is necessary before investing in detailed performance testing. It's crucial to recognize that initial estimates are meant to be refined, not precise forecasts. The other options represent misinterpretations of what a 'back-of-envelope' calculation aims to achieve.
12 / 26
Reviewer: 'I'm seeing a potential bottleneck here. The team estimates 10,000 daily active users (DAU) generating an average of 5 events per user per day. If we're using a REST API with a 20ms latency overhead and assuming synchronous processing for each event, what's a reasonable back-of-envelope estimate for the total system latency? Let's keep it simple.'This question tests understanding of applying basic estimation principles to a real-world scenario. The initial calculation is flawed because it doesn't consider potential bottlenecks like rate limits or increased latency during peak periods. A back-of-envelope estimate should acknowledge these factors and provide a range rather than a single, overly optimistic value. Remember, the goal isn't precision; it's identifying potential issues quickly.
13 / 26
Senior Dev: 'Okay team, we're migrating to this new microservice. Initial estimates put the number of requests per second at around 500. But I'm seeing some concerns about scaling. Let's run a quick back-of-envelope calculation to see if that's feasible. Assume each request takes roughly 10ms of processing time and we have 10 instances running in parallel. What's the best way to frame the result for discussion?', This question tests understanding of communicating results from back-of-envelope estimates in a professional setting. The key here isn't just the calculation itself (which is simplified), but how to frame the result and acknowledge its limitations. Options A and D are overly confident and fail to account for potential issues; option B provides an unrealistic target, while option C accurately reflects the nature of a preliminary estimate—emphasizing the need for further investigation—making it the most appropriate response.
14 / 26
During a sprint review, the frontend team presents their redesigned user profile page. They've estimated it will require 20KB of storage per profile and expect 1 million users in the next year. The team wants to discuss potential infrastructure costs. Which statement best describes how you would frame a back-of-envelope estimate for this scenario?
The correct answer (option 2) acknowledges the initial calculation but immediately adds the crucial element of considering ongoing costs and growth. Options A and B present overly simplistic or potentially disastrous calculations. Option D is misleading as it relies on a flawed assumption about current usage being representative of future needs.
15 / 26
During a standup meeting, Sarah (Backend) says: 'We're building a new recommendation engine. We're processing about 500,000 user interactions per hour and each interaction takes roughly 2ms to process on our current infrastructure. I'm thinking we need to scale up the number of servers.' John (Frontend), immediately responds with: 'That sounds like a lot! What's your back-of-envelope estimate for the overall system throughput?' Which statement best captures John's request for Sarah to provide a useful back-of-envelope estimate?
John is asking for a high-level, rapid estimation – a 'back-of-envelope' calculation. Option A demands precision far beyond what's feasible initially; option B focuses solely on an hourly metric without considering the processing time. Options C and D are too vague and don't directly relate to the core concept of estimating system throughput based on key inputs like interaction rate and latency. The correct answer, focusing on peak load, aligns with the purpose of a back-of-envelope estimate – a quick, pragmatic approach.
16 / 26
During a sprint planning session, the team is discussing the performance of a new feature that generates daily reports. The lead engineer states: 'We're generating approximately 50,000 reports per day, each containing roughly 1KB of data. We're using a simple database query to retrieve this information. Let's quickly estimate the server load to ensure we have sufficient resources.' Which phrasing best describes the situation and the engineer's need for a back-of-envelope estimate?
The engineer isn't looking for a perfect prediction; they need a preliminary assessment to gauge whether their current setup can handle the load. A back-of-envelope estimate allows them to quickly identify potential bottlenecks and determine if scaling is necessary before investing in detailed performance testing. It's crucial to recognize that initial estimates are meant to be refined, not precise forecasts. The other options represent misinterpretations of what a 'back-of-envelope' calculation aims to achieve.
17 / 26
Reviewer: 'I'm seeing a potential bottleneck here. The team estimates 10,000 daily active users (DAU) generating an average of 5 events per user per day. If we're using a REST API with a 20ms latency overhead and assuming synchronous processing for each event, what's a reasonable back-of-envelope estimate for the total system latency? Let's keep it simple.'This question tests understanding of applying basic estimation principles to a real-world scenario. The initial calculation is flawed because it doesn't consider potential bottlenecks like rate limits or increased latency during peak periods. A back-of-envelope estimate should acknowledge these factors and provide a range rather than a single, overly optimistic value. Remember, the goal isn't precision; it's identifying potential issues quickly.
18 / 26
Senior Dev: 'Okay team, we're migrating to this new microservice. Initial estimates put the number of requests per second at around 500. But I'm seeing some concerns about scaling. Let's run a quick back-of-envelope calculation to see if that's feasible. Assume each request takes roughly 10ms of processing time and we have 10 instances running in parallel. What's the best way to frame the result for discussion?', This question tests understanding of communicating results from back-of-envelope estimates in a professional setting. The key here isn't just the calculation itself (which is simplified), but how to frame the result and acknowledge its limitations. Options A and D are overly confident and fail to account for potential issues; option B provides an unrealistic target, while option C accurately reflects the nature of a preliminary estimate—emphasizing the need for further investigation—making it the most appropriate response.
19 / 26
During a sprint review, the frontend team presents their redesigned user profile page. They've estimated it will require 20KB of storage per profile and expect 1 million users in the next year. The team wants to discuss potential infrastructure costs. Which statement best describes how you would frame a back-of-envelope estimate for this scenario?
The correct answer (option 2) acknowledges the initial calculation but immediately adds the crucial element of considering ongoing costs and growth. Options A and B present overly simplistic or potentially disastrous calculations. Option D is misleading as it relies on a flawed assumption about current usage being representative of future needs.
20 / 26
During a standup meeting, Sarah (Backend) says: 'We're building a new recommendation engine. We're processing about 500,000 user interactions per hour and each interaction takes roughly 2ms to process on our current infrastructure. I'm thinking we need to scale up the number of servers.' John (Frontend), immediately responds with: 'That sounds like a lot! What's your back-of-envelope estimate for the overall system throughput?' Which statement best captures John's request for Sarah to provide a useful back-of-envelope estimate?
John is asking for a high-level, rapid estimation – a 'back-of-envelope' calculation. Option A demands precision far beyond what's feasible initially; option B focuses solely on an hourly metric without considering the processing time. Options C and D are too vague and don't directly relate to the core concept of estimating system throughput based on key inputs like interaction rate and latency. The correct answer, focusing on peak load, aligns with the purpose of a back-of-envelope estimate – a quick, pragmatic approach.
21 / 26
During a sprint planning session, the team is discussing the performance of a new feature that generates daily reports. The lead engineer states: 'We're generating approximately 50,000 reports per day, each containing roughly 1KB of data. We're using a simple database query to retrieve this information. Let's quickly estimate the server load to ensure we have sufficient resources.' Which phrasing best describes the situation and the engineer's need for a back-of-envelope estimate?
The engineer isn't looking for a perfect prediction; they need a preliminary assessment to gauge whether their current setup can handle the load. A back-of-envelope estimate allows them to quickly identify potential bottlenecks and determine if scaling is necessary before investing in detailed performance testing. It's crucial to recognize that initial estimates are meant to be refined, not precise forecasts. The other options represent misinterpretations of what a 'back-of-envelope' calculation aims to achieve.
22 / 26
Reviewer: 'I'm seeing a potential bottleneck here. The team estimates 10,000 daily active users (DAU) generating an average of 5 events per user per day. If we're using a REST API with a 20ms latency overhead and assuming synchronous processing for each event, what's a reasonable back-of-envelope estimate for the total system latency? Let's keep it simple.'This question tests understanding of applying basic estimation principles to a real-world scenario. The initial calculation is flawed because it doesn't consider potential bottlenecks like rate limits or increased latency during peak periods. A back-of-envelope estimate should acknowledge these factors and provide a range rather than a single, overly optimistic value. Remember, the goal isn't precision; it's identifying potential issues quickly.
23 / 26
Senior Dev: 'Okay team, we're migrating to this new microservice. Initial estimates put the number of requests per second at around 500. But I'm seeing some concerns about scaling. Let's run a quick back-of-envelope calculation to see if that's feasible. Assume each request takes roughly 10ms of processing time and we have 10 instances running in parallel. What's the best way to frame the result for discussion?', This question tests understanding of communicating results from back-of-envelope estimates in a professional setting. The key here isn't just the calculation itself (which is simplified), but how to frame the result and acknowledge its limitations. Options A and D are overly confident and fail to account for potential issues; option B provides an unrealistic target, while option C accurately reflects the nature of a preliminary estimate—emphasizing the need for further investigation—making it the most appropriate response.
24 / 26
During a sprint review, the frontend team presents their redesigned user profile page. They've estimated it will require 20KB of storage per profile and expect 1 million users in the next year. The team wants to discuss potential infrastructure costs. Which statement best describes how you would frame a back-of-envelope estimate for this scenario?
The correct answer (option 2) acknowledges the initial calculation but immediately adds the crucial element of considering ongoing costs and growth. Options A and B present overly simplistic or potentially disastrous calculations. Option D is misleading as it relies on a flawed assumption about current usage being representative of future needs.
25 / 26
During a standup meeting, Sarah (Backend) says: 'We're building a new recommendation engine. We're processing about 500,000 user interactions per hour and each interaction takes roughly 2ms to process on our current infrastructure. I'm thinking we need to scale up the number of servers.' John (Frontend), immediately responds with: 'That sounds like a lot! What's your back-of-envelope estimate for the overall system throughput?' Which statement best captures John's request for Sarah to provide a useful back-of-envelope estimate?
John is asking for a high-level, rapid estimation – a 'back-of-envelope' calculation. Option A demands precision far beyond what's feasible initially; option B focuses solely on an hourly metric without considering the processing time. Options C and D are too vague and don't directly relate to the core concept of estimating system throughput based on key inputs like interaction rate and latency. The correct answer, focusing on peak load, aligns with the purpose of a back-of-envelope estimate – a quick, pragmatic approach.
26 / 26
During a sprint planning session, the team is discussing the performance of a new feature that generates daily reports. The lead engineer states: 'We're generating approximately 50,000 reports per day, each containing roughly 1KB of data. We're using a simple database query to retrieve this information. Let's quickly estimate the server load to ensure we have sufficient resources.' Which phrasing best describes the situation and the engineer's need for a back-of-envelope estimate?
The engineer isn't looking for a perfect prediction; they need a preliminary assessment to gauge whether their current setup can handle the load. A back-of-envelope estimate allows them to quickly identify potential bottlenecks and determine if scaling is necessary before investing in detailed performance testing. It's crucial to recognize that initial estimates are meant to be refined, not precise forecasts. The other options represent misinterpretations of what a 'back-of-envelope' calculation aims to achieve.
Frequently Asked Questions
What does the "Back-of-Envelope Estimates — Estimation Language Exercises" exercise cover?
Narrate order-of-magnitude calculations: DAU, storage, bandwidth, and growth extrapolations in system design English. Advanced exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Back-of-Envelope Estimates — Estimation Language Exercises"?
This exercise has 26 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Estimation Language exercises?
Browse the full Estimation Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.