10. Capacity, Performance and Scalability Engineering

Introduction and Context

Reliability is not achieved merely by keeping services technically available. A system may be operational yet fail its users because responses are too slow, requests are rejected, queues grow without bound, or infrastructure costs rise beyond sustainable limits. Capacity, performance and scalability engineering address this problem by connecting user demand with the resources, architecture and operating practices required to serve that demand reliably.

In Site Reliability Engineering (SRE), capacity planning is closely related to service-level objectives (SLOs), error budgets, incident management and observability. A service that meets its availability target but violates its latency objective is not reliable from the user’s perspective. Similarly, a service that performs well under normal conditions but collapses during a predictable seasonal peak has been inadequately engineered.

Capacity engineering asks whether sufficient resources exist to handle expected workload. Performance engineering asks how efficiently and quickly the system responds. Scalability engineering asks how the system behaves when workload or resource levels change. These concerns overlap but are not identical. A larger machine may increase capacity without improving architectural scalability; caching may reduce latency without increasing computational capacity; and horizontal scaling may increase throughput while introducing coordination overhead.

This chapter develops methods for workload modelling, queueing analysis, saturation diagnosis, performance testing, forecasting and autoscaling. It also examines the economic and governance decisions that arise when organizations balance cost, performance and reliability across cloud, on-premises and hybrid environments.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Model workloads using demand, concurrency, throughput and resource-consumption measures.

2. Apply queueing concepts and utilization analysis to identify performance limits.

3. Distinguish latency, throughput, saturation, capacity and scalability.

4. Design appropriate load, stress, spike, soak and capacity tests.

5. Forecast capacity using historical data, growth assumptions and uncertainty ranges.

6. Evaluate autoscaling policies and recognize their failure modes.

7. Diagnose bottlenecks across application, database, network and platform layers.

8. Make defensible cost–performance–reliability decisions in cloud and hybrid systems.

Capacity, Performance and Scalability: Related but Distinct Ideas

Capacity is the maximum sustainable workload that a system can serve while remaining within defined performance and reliability objectives. Capacity is therefore not simply the number of CPU cores or the amount of memory installed. It depends on workload characteristics, service-level targets, failure assumptions and the duration for which demand must be sustained.

Performance describes how a system behaves under a particular workload. Important dimensions include response time, throughput, resource utilization, error rate and efficiency. Performance is usually workload-specific: a service may respond quickly to reads but slowly to writes, or handle small messages efficiently but struggle with large payloads.

Scalability is the ability of a system to accommodate changing workload by adding resources or modifying its configuration while preserving acceptable performance and reliability. Vertical scaling increases the capacity of an individual resource. Horizontal scaling adds instances or partitions. Diagonal scaling combines both approaches. Scalability is not guaranteed by cloud elasticity; an application must be architecturally capable of using additional resources.

A useful distinction is between elasticity and scalability. Scalability concerns the capacity relationship between workload and resources. Elasticity concerns how automatically and rapidly resources adapt to changing demand. An application can be scalable but not elastic if operators must manually add instances. It can also be elastic in infrastructure terms while failing to scale because a shared database or lock remains a bottleneck.

Important measures include:

• Throughput: completed requests, transactions or bytes per unit of time.
• Latency: elapsed time between an operation’s initiation and completion.
• Concurrency: number of operations in progress at a point in time.
• Utilization: proportion of a resource’s capacity being used.
• Saturation: degree to which demand exceeds or approaches a resource’s ability to serve it.
• Availability: proportion of time a service is usable according to an agreed definition.
• Tail latency: high-percentile latency, such as the 95th, 99th or 99.9th percentile.

Average latency can conceal serious user impact. If 99 percent of requests complete in 100 milliseconds but 1 percent require 20 seconds, the average may appear acceptable while a significant group experiences failure-like behaviour. SRE teams therefore use percentile objectives and examine latency distributions rather than relying only on means.

Workload Modelling: Describing Demand Before Measuring Capacity

Capacity decisions begin with a workload model. A workload model describes what users and systems ask the service to do, how frequently they ask, and how resource-intensive each operation is. A useful model includes request mix, arrival pattern, payload size, dependency calls, geographic distribution, session behaviour and consistency requirements.

For example, an online retail service might receive 70 percent product reads, 20 percent searches and 10 percent checkout operations. Checkout may be less frequent but much more expensive because it invokes inventory, payment, fraud and order-management systems. Treating all requests as identical would produce a misleading capacity estimate.

Demand can be represented in several ways:

• Requests per second or transactions per minute.
• Concurrent users or active sessions.
• Events per second in a streaming system.
• Data volume, such as gigabytes written per hour.
• Work units, where each operation is weighted by computational cost.

The distinction between arrival rate and service rate is central. Arrival rate is the rate at which work reaches a component. Service rate is the rate at which that component can complete work. If arrivals persistently exceed service capacity, a queue grows, latency increases and requests may eventually time out or be rejected.

Workload models should include normal, peak, exceptional and recovery conditions. A daily average is rarely sufficient. Engineers should examine peak-to-average ratios, burst duration, correlated demand and the effect of retries. A failed dependency can cause clients to retry simultaneously, converting a moderate workload into a retry storm. Capacity planning that excludes retries may substantially underestimate demand.

A practical modelling process is to:

1. Identify business transactions and technical operations.

2. Measure their frequency, size and dependency pattern.

3. Separate steady-state, seasonal and burst demand.

4. Define workload assumptions and confidence ranges.

5. Map each operation to resource consumption.

6. Validate the model against production observations.

The model must remain explicit about uncertainty. Forecasting 10,000 requests per second is less useful than stating that expected demand is 8,000–10,000 requests per second, with a possible promotional burst of 15,000 requests per second for ten minutes.

Queueing Concepts and the Onset of Saturation

Queueing theory provides a conceptual and mathematical foundation for understanding why latency rises sharply near saturation. A queueing system contains arrivals, waiting space, one or more servers and a service discipline. In computing, the server may be a CPU, database connection, worker thread, disk, network link or downstream API.

Little’s Law is one of the most useful relationships:

L = λW

where L is the average number of items in the system, λ is the average arrival rate and W is the average time an item spends in the system. In operational terms, if a service processes 200 requests per second and the average request takes 0.5 seconds, approximately 100 requests are in flight. The relationship applies broadly, provided the system is stable and the measurements refer to the same scope.

Utilization is commonly expressed as:

ρ = λ / μ

where λ is arrival rate and μ is service rate. As utilization approaches 1, waiting time generally becomes highly sensitive to variability. A resource operating at 50 percent utilization may absorb bursts; one operating continuously at 95 percent has little headroom and may experience rapidly increasing latency. The exact safe operating point depends on variability, workload objectives and the cost of failure.

Queueing behaviour is affected not only by average demand but also by variability in arrivals and service time. Long-running requests can occupy workers and delay short requests. Synchronized batch jobs can create bursts. A queue may hide a bottleneck temporarily, but increasing queue depth is usually an early warning of saturation rather than a solution.

Distributed systems contain multiple queues. A user request may wait for an application thread, a database connection, a database lock, a storage operation and a remote API. The end-to-end latency is influenced by serial dependencies, parallel fan-out and retries. In a fan-out request, the probability of encountering a slow child request increases as the number of dependencies grows. This makes tail-latency control especially important.

Finding Bottlenecks Through Saturation Analysis

A bottleneck is the component that most limits useful throughput or violates the service objective. Bottlenecks move as workload changes. CPU may be limiting at low concurrency, while database connections, garbage collection, storage I/O or network bandwidth become limiting at higher load.

Effective diagnosis combines four classes of evidence:

1. Demand indicators: request rate, queue depth, active users and payload size.

2. Resource indicators: CPU, memory, disk I/O, network, connection pools and thread pools.

3. Outcome indicators: latency percentiles, errors, timeouts and rejected work.

4. Dependency indicators: downstream latency, status codes, retries and saturation signals.

A high CPU reading does not automatically identify the root cause. CPU may be high because of useful work, inefficient serialization, excessive logging, encryption, garbage collection or a retry storm. Conversely, low CPU with high latency may indicate lock contention, blocked I/O, exhausted connection pools or a slow dependency.

A disciplined investigation establishes a baseline, changes one relevant variable, observes the response and verifies the result under representative workload. Flame graphs, distributed traces, database execution plans and queue-depth metrics can reveal where time is spent. Correlation is not proof: a deployment and a latency increase may coincide, but controlled comparison or rollback evidence is needed to establish causation.

A common diagnostic technique is bottleneck isolation. Increase load gradually while observing each resource. The first resource whose utilization or queue grows disproportionately is a candidate bottleneck. Then test whether increasing that resource improves throughput. If adding application instances does not improve throughput because the database is saturated, the database or its access pattern is the effective constraint.

Performance and Capacity Testing

Production observation is indispensable, but controlled testing exposes limits before users discover them. Test environments should resemble production in software version, data shape, configuration, dependency behaviour and network characteristics. Perfect duplication is often impossible, so differences must be documented and interpreted.

A load test evaluates behaviour under an expected workload. A stress test increases demand beyond the expected level to discover the failure boundary and recovery behaviour. A spike test examines abrupt changes in demand. A soak test runs for an extended period to reveal leaks, resource fragmentation, cache degradation or cumulative queue growth. A capacity test systematically identifies the maximum sustainable workload under stated objectives.

A credible test plan defines:

• workload mix and arrival pattern;
• target throughput and concurrency;
• latency and error objectives;
• test duration and warm-up period;
• data volume and cache state;
• success and failure criteria;
• monitoring and rollback arrangements.

Open-loop load generation controls arrival rate independently of system response and is useful for exposing queue growth. Closed-loop testing generates another request only after the previous one completes, which can conceal overload because the generator naturally slows when the system becomes slow. The choice must match the question being investigated.

Tests should measure percentiles, throughput, errors, saturation and recovery, not merely whether a script completed. A test that reports 99 percent success may still violate an SLO if the failed 1 percent consists of critical transactions. Test traffic must also be governed carefully: authorization, privacy, rate limits and downstream side effects require explicit controls.

Capacity Forecasting and Planning Horizons

Capacity planning translates expected demand into infrastructure and operational decisions. Short-term planning addresses events such as launches or seasonal peaks. Medium-term planning guides procurement, reservations, architecture changes and staffing. Long-term planning considers product growth, platform migration and strategic constraints.

A basic forecast can use historical growth, seasonal decomposition and business drivers. However, extrapolating a trend line is insufficient when a new feature changes request mix or when demand is constrained by current poor performance. Forecasts should therefore combine statistical evidence with product and organizational knowledge.

A useful planning calculation is:

Required capacity = forecast peak demand × safety factor / capacity per unit

The safety factor should reflect forecast uncertainty, burstiness, failure scenarios and the time required to add capacity. It should not be selected arbitrarily. Engineers should model several scenarios: expected, high-growth, exceptional-event and degraded-capacity cases.

Headroom has economic value. It absorbs forecast error, permits maintenance, supports failover and reduces the probability of operating near a steep queueing curve. Excessive headroom, however, increases cost and may hide inefficient architecture. Capacity plans should state both the target operating point and the consequences of exceeding it.

Multi-region and hybrid systems require additional analysis. Capacity may need to be reserved independently by region because traffic cannot always move freely during an outage. Data sovereignty, network latency, licensing and egress charges may constrain placement. Failover capacity should account for the possibility that the surviving region receives more than its normal workload.

Autoscaling: Elasticity with Control-Loop Risks

Autoscaling is a feedback system. Metrics represent observed state, a policy compares that state with a target, and an actuator adds or removes resources. The controller operates with measurement delay, provisioning delay and workload variability. These delays can cause under-scaling, over-scaling or oscillation.

Common scaling signals include CPU utilization, request rate, queue depth, concurrent requests, latency and business throughput. CPU is convenient but often indirect. Queue depth or work per instance may provide a more meaningful signal for worker systems. Latency is valuable as an outcome measure but can be too late or too noisy as the sole scaling trigger.

Effective autoscaling policies require:

• a metric tied to actual capacity consumption;
• minimum and maximum bounds;
• scale-out and scale-in stabilization windows;
• cooldown periods appropriate to provisioning time;
• protection against flapping;
• quotas and budget controls;
• graceful connection draining and termination;
• a fallback plan when scaling cannot keep up.

Autoscaling cannot repair a fundamentally non-scalable dependency. If every new application instance adds connections to an already saturated database, scaling may worsen the problem. It can also create a thundering herd when newly launched instances simultaneously warm caches or load configuration. Rate limiting, admission control, load shedding and graceful degradation are complementary controls.

Cost–Performance–Reliability Trade-offs

Capacity decisions are economic decisions as well as technical ones. A faster instance, replicated database, reserved capacity or additional region may improve performance and resilience but increase direct and indirect cost. The relevant comparison is not infrastructure price alone; it includes lost transactions, customer dissatisfaction, operational effort, energy use and risk exposure.

Cloud environments offer rapid provisioning and elastic capacity, but variable consumption costs can become difficult to predict. Hybrid environments may reduce dependence on a provider but introduce synchronization, network and operational complexity. On-premises capacity may have lower marginal cost after procurement but longer lead times and less flexibility.

Engineering choices should be evaluated against explicit SLOs and business criticality. A payment path may justify redundancy and low tail latency that would be excessive for an internal reporting dashboard. Cost optimization must not silently reduce error-budget protection. Governance should require owners to document assumptions, thresholds, approval authority and rollback conditions.

FinOps and SRE practices are complementary. Cost metrics should be associated with meaningful units such as cost per transaction, cost per active customer or cost per gigabyte processed. Rightsizing without examining performance can increase queueing and incident risk. Conversely, indiscriminate overprovisioning can conceal defects and reduce funds available for reliability improvements.

Illustrative Case Study: Scaling a Flash-Sale Platform

Background

A fictional online retailer, Northstar Commerce, operates a cloud-based platform for ordinary demand of 2,000 requests per second. Its SLO requires 99 percent of product-page requests to complete within 300 milliseconds and checkout requests within 800 milliseconds. A planned promotional event is expected to produce 8,000 requests per second, with a possible ten-minute burst of 12,000 requests per second.

Situation and Problem

During a rehearsal using average traffic, application CPU remained below 60 percent and the test appeared successful. During a more realistic test with the expected request mix, checkout latency exceeded three seconds and database connection queues grew rapidly. Adding application instances produced little improvement.

Analysis

Tracing showed that product pages generated many cache hits, while checkout invoked inventory, pricing, payment and order services. The inventory database used a shared lock for stock reservation. At approximately 2,500 checkout transactions per second, lock wait time increased sharply. The application tier was not the primary bottleneck. Furthermore, an unsuccessful payment retry policy allowed clients to retry three times, multiplying load during slow periods.

Queueing analysis showed that the database’s effective service rate for the reservation operation was below the anticipated arrival rate. The existing autoscaler used application CPU, which remained moderate because requests were blocked waiting for the database. Consequently, the controller received a misleading signal.

Approach and Solution

Northstar introduced a workload model separating reads, searches and checkout operations. It changed autoscaling for checkout workers to use queue depth and oldest-message age, while retaining CPU as a secondary signal. Inventory reservation was redesigned to reduce lock duration and use partitioning by product group. A bounded queue and admission control limited new checkout work when the reservation subsystem approached saturation. The retry policy used exponential backoff with jitter and a maximum retry budget.

Capacity tests included normal load, the projected burst, a database-degraded test and a region-failure scenario. Product-page traffic was served from a distributed cache, while checkout capacity was reserved independently. Dashboards displayed request mix, queue age, lock waits, tail latency, rejected work and cost per completed order.

Outcome

The revised design sustained the expected promotional workload within the stated objectives and degraded by rejecting or delaying non-critical requests rather than allowing the entire platform to time out. The test also showed that maximum checkout capacity, rather than application CPU, determined the practical event limit. Management therefore reduced the advertised inventory release rate to remain within a controlled operating envelope.

Learning Points

The case demonstrates that scaling the visible tier is ineffective when a shared dependency is the bottleneck. It also shows why workload mix, queueing signals, retry behaviour and graceful degradation must be included in capacity plans. Finally, capacity is a business decision: the organization chose a controlled sales rate instead of accepting system-wide failure.

Challenges, Risks and Common Mistakes

Several mistakes recur in capacity engineering. Planning from averages ignores peaks and variability. Using CPU as a universal scaling metric misses I/O, lock and queue bottlenecks. Testing with synthetic data that lacks production cardinality produces false confidence. Measuring only average latency hides tail behaviour. Ignoring warm-up, caches and connection pools makes results difficult to reproduce.

Another risk is capacity feedback. Slow systems cause retries, retries increase demand, increased demand causes further slowdown, and the resulting cascade may be mistaken for an isolated resource shortage. Timeouts should be bounded and coordinated across service layers. Queues should have limits; unlimited queues convert overload into delayed failure and memory exhaustion.

Capacity tests can also harm production or external providers. They may expose personal data, create financial transactions or violate contractual rate limits. Test environments require access control, synthetic or anonymized data, and clear authorization. Results should be retained with configuration, software version and assumptions so that later comparisons are meaningful.

Governance, Ethics and Professional Responsibility

Reliability decisions affect users unequally. Aggressive load shedding may preserve a core service while disproportionately excluding particular regions, customers or accessibility users. Engineers should define degradation policies transparently and assess whether automated decisions create unfair outcomes.

Capacity management also involves privacy and security. Observability data may contain identifiers or payload fragments; performance testing may process sensitive information. Data minimization, retention controls and appropriate authorization are essential. Autoscaling and cost controls require governance because a faulty policy can create a financial incident as well as a technical one.

Professional practice requires communicating uncertainty. Capacity claims should identify test conditions, confidence limits and untested dependencies. Presenting a single maximum number as a guarantee is misleading. Decisions should be reviewable, reversible where possible and connected to business and SLO ownership.

Automation, Analytics and Emerging Practice

Modern platforms automate provisioning, testing and telemetry collection. Infrastructure as code makes capacity configurations reproducible. Continuous load testing can detect performance regressions before release. Distributed tracing and eBPF-based observability can expose kernel, network and process-level behaviour with limited application changes.

Machine-learning methods are increasingly used for anomaly detection, demand forecasting and predictive scaling. They can identify seasonal patterns that threshold-based policies miss, but they require careful validation. Forecast errors, data drift and opaque decisions can cause underprovisioning or uncontrolled cost. Predictive systems should have conservative bounds and deterministic fallbacks.

Emerging architectures—including serverless computing, event-driven systems, edge platforms and workload-aware scheduling—change the location and form of capacity constraints rather than eliminating them. Serverless systems may scale execution rapidly while encountering concurrency quotas, cold-start latency or downstream database limits. Edge deployment can reduce latency but increases fleet-management and consistency complexity. The enduring principle is to measure the complete service path, not merely the compute layer.

Best Practices for Practitioners

A mature capacity practice typically does the following:

• defines SLOs and capacity objectives together;
• models workload mix, peaks, retries and failure conditions;
• monitors latency percentiles, queues, saturation and errors;
• identifies the true bottleneck before scaling;
• tests expected, burst, stress, soak and recovery behaviour;
• uses scaling signals tied to work rather than convenient proxies;
• maintains documented headroom and failover capacity;
• links infrastructure cost to useful business outcomes;
• applies bounded queues, timeouts, rate limits and load shedding;
• reviews forecasts and assumptions after production events;
• treats automated scaling as a controlled feedback system.

Chapter Summary

Capacity, performance and scalability engineering connect workload demand with system resources and service objectives. Capacity is the sustainable workload a system can serve within defined limits; performance concerns response behaviour under a workload; scalability concerns adaptation as workload or resources change. Workload modelling must represent request mix, bursts, dependencies, retries and uncertainty.

Queueing concepts explain why latency rises near saturation. Little’s Law relates concurrency, arrival rate and time in system, while utilization analysis helps identify diminishing headroom. Bottleneck diagnosis requires correlated evidence from demand, resources, outcomes and dependencies. Load, stress, spike, soak and capacity tests answer different questions and must measure percentiles, errors, queues and recovery.

Forecasting combines historical data with business assumptions and scenario analysis. Autoscaling is a delayed feedback loop that needs suitable signals, bounds and stabilization. Finally, capacity choices involve cost, performance, reliability, governance and user impact. The strongest SRE practice treats capacity as an observable, testable and continuously revised engineering discipline.

Key Terms

Capacity: Maximum sustainable workload within specified performance and reliability objectives.

Performance: Behaviour of a system under a defined workload, including latency, throughput and resource use.

Scalability: Ability to accommodate changing workload by adding or adjusting resources while preserving objectives.

Elasticity: Ability to adapt resource levels automatically or rapidly as demand changes.

Throughput: Amount of completed work per unit of time.

Latency: Time taken for an operation to complete.

Concurrency: Number of operations in progress at a given time.

Utilization: Proportion of a resource’s available capacity being used.

Saturation: Condition in which demand approaches or exceeds a component’s service capability.

Tail latency: High-percentile response time representing slow requests.

Arrival rate: Rate at which work enters a system.

Service rate: Rate at which a component completes work.

Queue depth: Number of items waiting or being processed in a queue.

Little’s Law: Relationship stating that average items in a system equal arrival rate multiplied by average time in the system.

Load test: Test of system behaviour under an expected workload.

Stress test: Test that increases demand beyond expected operating conditions.

Soak test: Extended test intended to reveal cumulative or long-duration problems.

Headroom: Reserved unused capacity available for variability, maintenance or failure.

Autoscaling: Automated adjustment of resource levels in response to observed conditions.

Load shedding: Deliberate rejection or reduction of work to preserve critical service behaviour.

Review Questions

Short Answer Questions

1. Distinguish capacity, performance and scalability.

2. Why can average latency be misleading in SRE practice?

3. State Little’s Law and explain its variables.

4. What is the difference between a load test and a stress test?

5. Why is CPU utilization not always a suitable autoscaling signal?

Long Answer Questions

1. Explain how workload modelling supports reliable capacity planning.

2. Discuss queueing, utilization and saturation in distributed services.

3. Describe a systematic method for diagnosing a bottleneck.

4. Compare vertical, horizontal and diagonal scaling, including their limitations.

5. Explain how organizations should balance cost, performance and reliability in cloud and hybrid environments.

Analytical / Application Questions

1. A service receives 500 requests per second and has an average time in system of 0.4 seconds. Estimate the average number of requests in the system and explain the assumption used.

2. During a performance test, application CPU is 45 percent, database lock waits are rising and the 99th-percentile latency is increasing. Identify the likely bottleneck and propose two tests to validate your conclusion.

3. A queue-based worker service experiences a ten-minute demand burst that exceeds normal arrival rate by four times. Design an autoscaling and load-shedding strategy that protects latency, cost and recovery behaviour.

22. Multiple Choice Questions with Answers

Question 1

A service processes 200 requests per second with an average time in the system of 0.5 seconds. According to Little’s Law, what is the approximate average number of requests in the system?

A. 40

B. 100

C. 200

D. 400

Correct Answer: B. 100

Question 2

Which observation most strongly suggests that an application CPU-based autoscaler is using a misleading signal?

A. CPU is high and throughput increases proportionally

B. CPU is moderate while database connection queues and latency rise

C. CPU falls after traffic decreases

D. Memory usage remains stable during normal load

Correct Answer: B. CPU is moderate while database connection queues and latency rise

Question 3

What is the principal purpose of a soak test?

A. To test only the maximum instantaneous request rate

B. To verify user-interface accessibility

C. To reveal cumulative problems during extended operation

D. To measure source-code complexity

Correct Answer: C. To reveal cumulative problems during extended operation

Question 4

As utilization approaches 100 percent, queueing systems generally exhibit which behaviour?

A. Waiting time becomes less sensitive to variability

B. Latency tends to rise sharply and headroom diminishes

C. Throughput becomes independent of arrival rate

D. Retries automatically decrease

Correct Answer: B. Latency tends to rise sharply and headroom diminishes

Question 5

Which workload characteristic is most important when checkout requests are much more expensive than product-page reads?

A. Treating every request as identical

B. Modelling request mix and operation-specific resource consumption

C. Measuring only daily average traffic

D. Scaling solely according to memory capacity

Correct Answer: B. Modelling request mix and operation-specific resource consumption

Question 6

A spike test is primarily designed to evaluate a system’s response to what condition?

A. A sudden change in demand

B. A gradual long-term growth trend

C. A permanent reduction in storage size

D. A code review process

Correct Answer: A. A sudden change in demand

Question 7

Which action best limits a retry storm during dependency degradation?

A. Allowing unlimited immediate retries

B. Removing all request timeouts

C. Using bounded retries with exponential backoff and jitter

D. Increasing log verbosity without limits

Correct Answer: C. Using bounded retries with exponential backoff and jitter

Question 8

Why can adding application instances fail to increase system throughput?

A. Horizontal scaling always reduces capacity

B. A shared dependency may already be the bottleneck

C. More instances necessarily reduce network bandwidth to zero

D. Autoscaling works only for storage systems

Correct Answer: B. A shared dependency may already be the bottleneck

Question 9

Which statement best describes headroom?

A. Unused capacity reserved for variability, maintenance or failure

B. The maximum theoretical speed of a processor

C. The number of requests rejected during an outage

D. A measure of average code quality

Correct Answer: A. Unused capacity reserved for variability, maintenance or failure

Question 10

What is a major risk of predictive autoscaling based on machine learning?

A. It cannot use historical data

B. It eliminates the need for resource limits

C. Forecast error or data drift can cause underprovisioning or excess cost

D. It guarantees correct scaling for every workload

Correct Answer: C. Forecast error or data drift can cause underprovisioning or excess cost