6 exercises — express compute, storage, and database requirements, describe horizontal vs. vertical scaling, and present multi-year cost projections to stakeholders.
0 / 19 completed
1 / 19
A product manager asks: "What do we need to support 10M users?" Which opening statement is most appropriate for a capacity planning discussion?
Option C — names the three clarifying questions needed before any estimate can be made, and specifies what the output will be (compute, storage, network).
Why clarifying questions come first in capacity planning: • "10M users" is ambiguous: registered accounts vs. concurrent users are orders of magnitude apart • Traffic pattern determines peak load calculations • Target SLO determines redundancy requirements • Without these, any number you give will be meaningless or dangerously wrong
Key clarifying questions in capacity planning: • "Do you mean concurrent users or registered accounts?" • "What's the expected request rate per user?" • "What's the read/write ratio?" • "What's the expected data size per user?" • "What's our target SLO/uptime?" • "What's the expected growth rate over the next 12 months?" • "Are there geographic distribution requirements?"
Capacity planning vocabulary: • "concurrent users" — users active simultaneously; the key metric for infrastructure • "traffic pattern" — how load is distributed over time • "peak load" — maximum concurrent users; typically 3–5× average • "baseline load" — expected steady-state traffic • "traffic shaping" — controlling how traffic enters the system
2 / 19
You need to present compute requirements. Which statement is most complete?
Option C — derives the number of pods from first principles: concurrent users → rps → pods at target utilization → HA multiplier → final recommendation.
Compute capacity planning chain:
Concurrent users × requests/user/second = total rps target
Total rps ÷ rps per pod = raw pod count
÷ target CPU utilization (e.g. 60%) = pods needed for head room
× HA/redundancy factor = final pod count
Distributed across N availability zones
Compute vocabulary: • "pod" — Kubernetes unit; used interchangeably with "instance" in cloud contexts • "target utilization" — desired peak CPU %; 60–70% is common (leaves headroom for spikes) • "high availability" (HA) — architecture that continues operating through single failures • "availability zone" (AZ) — isolated datacenter in a cloud region • "N+1 redundancy" — one spare beyond the minimum needed • "instance class" — AWS: c5.2xlarge, m5.large etc.; GCP: n2-standard-4 etc. • "autoscaling" — automatically adding/removing pods based on load
Presenting compute requirements: • Start from user/request assumptions • Show the calculation chain explicitly • Specify target utilization (not 100%!) • Include HA requirements • Name the instance type or equivalent spec • Mention distribution across AZs
3 / 19
How do you correctly express a storage capacity requirement for a planning document?
Option C — itemised storage calculation with growth projection, replication factor, and a specific infrastructure recommendation.
Storage capacity planning structure:
Per-user data × user count = raw data per category
Sum across categories = total raw data per time period
× growth factor = data at end of planning horizon
× replication factor = total raw storage required
→ Recommended storage class + cost management strategy
Storage vocabulary: • "hot storage" — frequently accessed; high performance, higher cost (e.g., SSD-backed, S3 Standard) • "warm storage" — occasionally accessed; balanced cost/performance • "cold storage / archival" — rarely accessed; lowest cost (e.g., S3 Glacier, Azure Archive) • "lifecycle policy" — automatically transitions objects between storage classes based on age • "replication factor" — number of copies (typically 3 for durability in distributed storage) • "durability" — probability of not losing data (S3: 11 nines = 99.999999999%) • "provisioned capacity" — storage allocated in advance (vs. on-demand)
Common storage recommendations: • Primary/real-time data: S3 Standard, Google Cloud Storage Standard • Archival (>90 days): S3 Glacier, Azure Archive • Database backups: compressed + lifecycle to cold storage after 30 days • Always mention: "with a lifecycle policy to [cold storage] after [N days]"
4 / 19
How do you describe a horizontal scaling plan in plain English?
Option C — explains horizontal scaling vs. vertical, gives the scaling range, and names the bottleneck that limits further scaling.
Horizontal vs. vertical scaling: • Horizontal scaling (scale out) — adding more instances/pods of the same size • Vertical scaling (scale up) — upgrading to a larger instance (more CPU/RAM)
When to use each: • Stateless services → horizontal (preferred for cloud-native architectures) • Stateful single-node services (legacy DBs) → vertical until you can shard • "Scaling out" is preferred for modern microservices • "Scaling up" hits a ceiling (the largest available instance)
Capacity planning vocabulary for scaling: • "stateless pods" — instances that can be added/removed without affecting state • "load balancer" — distributes traffic across pods • "bottleneck" — the component that limits further scaling • "shard the [component]" — partition a single-node component into multiple nodes • "session store" — shared state (e.g., Redis) that can become a scaling bottleneck • "scaling ceiling" — the point at which current architecture cannot scale further • "architectural change required at N×" — the scaling limit of the current design
Naming bottlenecks is the most important part of a scaling plan — it shows you have thought beyond the immediate scaling need to the next constraint.
5 / 19
You are recommending database capacity for a write-heavy workload. Which recommendation is most complete?
Option C — specifies the workload (5,000 writes/second), names the recommended instance, gives the known scaling ceiling, and separates read and write scaling strategies.
Database capacity planning structure:
Current write load: [X] writes/second
Current/target instance: [type] handles up to [N] writes/second
Scaling ceiling: beyond [N] → [architectural change needed]
Read scaling: [read replicas / caching layer / CQRS]
Current read concern: [specific query type hitting primary]
Database scaling vocabulary: • "primary" / "primary instance" — the master write node • "read replica" — follower that handles read-only queries; reduces primary load • "write sharding" — partitioning write traffic across multiple primaries • "IOPS" — I/O operations per second; the throughput limit for storage • "connection pooling" — limiting the number of simultaneous DB connections (PgBouncer, etc.) • "query plan" — how the database executes a query; key for identifying bottlenecks • "CQRS" — Command Query Responsibility Segregation; separate write and read models
Separating write and read scaling is essential: Most applications are read-heavy. Read replicas solve read scaling without architectural changes. Write scaling (sharding) is expensive and complex — justify it with actual write load numbers before recommending it.
6 / 19
How do you present a multi-year capacity plan to a non-technical leadership audience?
Option C — translates technical infrastructure into cost projections, shows an optimization path, and recommends a governance process with a specific trigger.
Executive capacity plan structure:
Current cost: [baseline]
Growth assumption: [rate and period]
Projected cost at Year [N]: [amount] — [Nx growth]
Optimization lever: [action] → reduces to [amount]
Recommendation: review at [trigger], commit [lead time] in advance
Reserved instance vocabulary: • "on-demand pricing" — pay-as-you-go; most expensive but no commitment • "reserved instances" — 1 or 3-year commitment; typically 40–60% cheaper than on-demand • "savings plans" — AWS flexible commitment model • "spot instances" — cheapest (60–90% discount); can be interrupted; for fault-tolerant batch workloads • "committed use discounts" (CUD) — GCP equivalent of reserved instances
Governance recommendation phrases: • "Review at each 2× growth milestone" — specific trigger • "Commit 6 months ahead of need" — lead time for negotiation • "Lock in reserved pricing" — the action and its benefit • "Build in a 20% headroom buffer" — the planning rule
Leadership presentations should always answer: "What does this cost, when will costs change, and what can we do to control them?"
7 / 19
Sarah: "Hey team, we're launching the new recommendation engine. Initial projections show it'll handle around 500 requests per second at peak. We need to ensure our servers can keep up."
The key here is understanding that initial projections are just a starting point. While 500 RPS might seem sufficient initially, the question asks about *ensuring* they can keep up – implying potential future growth or unexpected spikes in demand. Simply stating 'sufficient' ignores the need for proactive monitoring and headroom to accommodate increases. The correct response highlights this crucial element of capacity planning: anticipating future needs rather than just reacting to current load.
8 / 19
Reviewer: 'The API response time is consistently above 500ms for these requests. We need to understand if the backend can handle the increased load from the new feature rollout.'
Which of the following responses best addresses the reviewer's concern, focusing on capacity planning during a code review discussion?
The reviewer's comment highlights a potential capacity issue. Simply stating that 500ms is 'acceptable' doesn't address the root cause – the increased load from the new feature rollout. The correct response acknowledges the concern and proposes a focused investigation into volume and bottlenecks to determine if scaling is needed. Options A and B are too dismissive, while option C ignores the potential problem entirely.
9 / 19
Sarah: "Hey team, we're launching the new recommendation engine. Initial projections show it'll handle around 500 requests per second at peak. We need to ensure our servers can keep up."
The key here is understanding that initial projections are just a starting point. While 500 RPS might seem sufficient initially, the question asks about *ensuring* they can keep up – implying potential future growth or unexpected spikes in demand. Simply stating 'sufficient' ignores the need for proactive monitoring and headroom to accommodate increases. The correct response highlights this crucial element of capacity planning: anticipating future needs rather than just reacting to current load.
10 / 19
Reviewer: 'The API response time is consistently above 500ms for these requests. We need to understand if the backend can handle the increased load from the new feature rollout.'
Which of the following responses best addresses the reviewer's concern, focusing on capacity planning during a code review discussion?
The reviewer's comment highlights a potential capacity issue. Simply stating that 500ms is 'acceptable' doesn't address the root cause – the increased load from the new feature rollout. The correct response acknowledges the concern and proposes a focused investigation into volume and bottlenecks to determine if scaling is needed. Options A and B are too dismissive, while option C ignores the potential problem entirely.
11 / 19
Sarah: "Hey team, we're launching the new recommendation engine. Initial projections show it'll handle around 500 requests per second at peak. We need to ensure our servers can keep up."
The key here is understanding that initial projections are just a starting point. While 500 RPS might seem sufficient initially, the question asks about *ensuring* they can keep up – implying potential future growth or unexpected spikes in demand. Simply stating 'sufficient' ignores the need for proactive monitoring and headroom to accommodate increases. The correct response highlights this crucial element of capacity planning: anticipating future needs rather than just reacting to current load.
12 / 19
Reviewer: 'The API response time is consistently above 500ms for these requests. We need to understand if the backend can handle the increased load from the new feature rollout.'
Which of the following responses best addresses the reviewer's concern, focusing on capacity planning during a code review discussion?
The reviewer's comment highlights a potential capacity issue. Simply stating that 500ms is 'acceptable' doesn't address the root cause – the increased load from the new feature rollout. The correct response acknowledges the concern and proposes a focused investigation into volume and bottlenecks to determine if scaling is needed. Options A and B are too dismissive, while option C ignores the potential problem entirely.
13 / 19
Sarah: "Hey team, we're launching the new recommendation engine. Initial projections show it'll handle around 500 requests per second at peak. We need to ensure our servers can keep up."
The key here is understanding that initial projections are just a starting point. While 500 RPS might seem sufficient initially, the question asks about *ensuring* they can keep up – implying potential future growth or unexpected spikes in demand. Simply stating 'sufficient' ignores the need for proactive monitoring and headroom to accommodate increases. The correct response highlights this crucial element of capacity planning: anticipating future needs rather than just reacting to current load.
14 / 19
Reviewer: 'The API response time is consistently above 500ms for these requests. We need to understand if the backend can handle the increased load from the new feature rollout.'
Which of the following responses best addresses the reviewer's concern, focusing on capacity planning during a code review discussion?
The reviewer's comment highlights a potential capacity issue. Simply stating that 500ms is 'acceptable' doesn't address the root cause – the increased load from the new feature rollout. The correct response acknowledges the concern and proposes a focused investigation into volume and bottlenecks to determine if scaling is needed. Options A and B are too dismissive, while option C ignores the potential problem entirely.
15 / 19
Context: David from DevOps is explaining a new monitoring dashboard to the team. He says, 'We're seeing a sustained spike in CPU utilization on Server A – consistently above 85%. This is impacting our application response times.' Which of the following statements best summarizes David's concern regarding capacity planning?
David's statement highlights a symptom – high CPU utilization – rather than the root cause. Option A jumps to a solution without understanding the underlying problem. Option B focuses on a potential fix, but doesn't address the immediate issue of exceeding capacity limits. Option C correctly identifies that this is likely a scaling issue requiring further analysis and action. Option D dismisses the concern entirely.
16 / 19
Context: During a Slack conversation about planned database migrations, Maria says, 'We need to ensure we have enough storage for all the new data generated by this feature. We're anticipating a 3x increase in records.' Which of the following is the MOST appropriate metric Maria should be focusing on when discussing capacity?
Maria's concern revolves around accommodating increased *data volume*. While connection rates and query times are relevant to performance, they don't directly address storage capacity. The 'rate at which new data is being written' (option 4) is a contributing factor but doesn't represent the total required storage. Focusing on available space ensures there's room for the projected growth.
17 / 19
Context: You are writing a PR description for a new feature that will significantly increase user traffic. The description reads: 'This release introduces a redesigned search interface with improved indexing and faster query performance.' Which of the following statements best complements this description to accurately reflect capacity planning considerations?
The initial description focuses on *functional* improvements. To address capacity planning, it's crucial to quantify the impact – how many users will be accessing this new feature simultaneously? A statement regarding concurrent user load is essential for determining if the infrastructure can handle the increased demand. The other options are irrelevant to capacity requirements.
18 / 19
Context: During a standup meeting, John (the Lead Developer) says, 'We're deploying the new API endpoint for user authentication. Initial tests suggest it can handle around 100 requests per second with no issues.' Sarah (a QA Engineer) asks, 'What's our plan if we see an increase in traffic?' Which of the following is the MOST appropriate response from John?
John needs to demonstrate an understanding of monitoring and adjustment. Option A is reactive and lacks a defined process. Option B highlights the importance of proactive observation and configuration tuning. Options C and D are off-topic regarding capacity planning – a new API version doesn't automatically solve scaling issues; focusing solely on user experience ignores infrastructure limitations.
19 / 19
Context: You are reviewing a code change that adds a new microservice handling image processing. The team lead comments: 'This service will be processing approximately 500 images per minute during peak times.' Which of the following statements best describes the key capacity planning consideration for this microservice?
While all the options are valid technical considerations, the core of capacity planning is about *throughput* – how many images the service can process within a given timeframe. The other options address performance and security aspects that support optimal throughput but don't directly quantify the required processing capacity. Ensuring sufficient speed to handle 500 images per minute is paramount.
What does the "Capacity Planning Language — Estimation Language Exercises" exercise cover?
Express compute, storage, and scaling requirements in clear English. Practice horizontal scaling, database capacity, and multi-year infrastructure projections. 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 "Capacity Planning Language — Estimation Language Exercises"?
This exercise has 19 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.