An enterprise organization is architecting a globally distributed e-commerce API backend on Google Cloud. To ensure a resilient, low-latency user experience during high-traffic events, the architecture team must define non-functional requirements for performance and availability. The requirements are as follows: Quantify user-perceived performance by tracking the proportion of requests served in under 200 ms. Establish an objective target to manage release risk and quantify acceptable downtime or degradation over a rolling 30-day period. Determine the maximum sustainable traffic throughput before latency violates the target threshold. Which approach should the cloud architect implement to establish these requirements and thresholds?

Define a request-based Latency Service Level Indicator (SLI) measuring the ratio of requests completed under 200 ms to total requests, establish a Service Level Objective (SLO) percentage goal over a rolling 30-day compliance period to derive an error budget, and perform load testing to determine the request rate threshold where 99th-percentile latency remains within the SLO limit.: What this solution is This solution establishes a formal Site Reliability Engineering (SRE) framework using Service Level Indicators (SLIs), Service Level Objectives (SLOs), and error budgets implemented via Google Cloud Observability and structured capacity planning. How it meets the requirements Quantifying low-latency performance: Defining a request-based Latency SLI as the ratio of valid requests resolved below the 200 ms Latency Threshold directly tracks the user experience at the application layer. Managing release risk and reliability: Setting a percentage goal for the SLO over a rolling 30-day compliance period provides an active error budget, allowing engineering teams to balance feature delivery velocity against system reliability. Determining traffic thresholds: Executing load testing to find the request rate where the 99th-percentile latency meets the SLO boundary allows the team to pinpoint exact scaling limits and capacity thresholds before production degradation occurs. Key advantages and capabilities Direct user alignment: Measures actual customer experience rather than raw underlying infrastructure resource metrics. Actionable error budgets: Provides a mathematical threshold (100% - SLO Goal) to govern deployment freezes and architectural remediation. Predictable capacity planning: Correlates load generation throughput directly against latency distributions. Native observability integration: Seamlessly tracks performance goals inside Cloud Monitoring and Cloud Service Mesh. Why this is optimal This approach directly targets the non-functional performance requirements by coupling quantifiable quality attributes (latency and availability) with empirical threshold testing, ensuring global system resilience without over-provisioning infrastructure.

StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Define Slo Performance Thresholds Gcp

Section: Identifying functional and non-functional requirements

An enterprise organization is architecting a globally distributed e-commerce API backend on Google Cloud. To ensure a resilient, low-latency user experience during high-traffic events, the architecture team must define non-functional requirements for performance and availability.

The requirements are as follows:

Quantify user-perceived performance by tracking the proportion of requests served in under 200 ms.
Establish an objective target to manage release risk and quantify acceptable downtime or degradation over a rolling 30-day period.
Determine the maximum sustainable traffic throughput before latency violates the target threshold.

Which approach should the cloud architect implement to establish these requirements and thresholds?

...

Establish a contractual Service Level Agreement (SLA) target for 100% availability, use Cloud Logging metrics tracking average CPU utilization per instance, and conduct stress testing to identify the exact breakpoint where Compute Engine virtual machines crash.

...

Implement a windowed Availability SLI measuring total connection concurrency per backend instance, define an annual SLO compliance period, and size backend resources so that peak utilization matches 100% capacity.

...

Define a request-based Latency Service Level Indicator (SLI) measuring the ratio of requests completed under 200 ms to total requests, establish a Service Level Objective (SLO) percentage goal over a rolling 30-day compliance period to derive an error budget, and perform load testing to determine the request rate threshold where 99th-percentile latency remains within the SLO limit.

...

Configure an infrastructure-level Availability SLI based on internal ICMP ping response times across Compute Engine VMs, configure alerting policies in Cloud Monitoring for peak disk I/O, and set regional quota limits to trigger autoscaling.

...

Explanations

What this solution is

This solution establishes a formal Site Reliability Engineering (SRE) framework using Service Level Indicators (SLIs), Service Level Objectives (SLOs), and error budgets implemented via Google Cloud Observability and structured capacity planning.

How it meets the requirements

Quantifying low-latency performance: Defining a request-based Latency SLI as the ratio of valid requests resolved below the 200 ms Latency Threshold directly tracks the user experience at the application layer.
Managing release risk and reliability: Setting a percentage goal for the SLO over a rolling 30-day compliance period provides an active error budget, allowing engineering teams to balance feature delivery velocity against system reliability.
Determining traffic thresholds: Executing load testing to find the request rate where the 99th-percentile latency meets the SLO boundary allows the team to pinpoint exact scaling limits and capacity thresholds before production degradation occurs.

Key advantages and capabilities

Direct user alignment: Measures actual customer experience rather than raw underlying infrastructure resource metrics.
Actionable error budgets: Provides a mathematical threshold (100% - SLO Goal) to govern deployment freezes and architectural remediation.
Predictable capacity planning: Correlates load generation throughput directly against latency distributions.
Native observability integration: Seamlessly tracks performance goals inside Cloud Monitoring and Cloud Service Mesh.

Why this is optimal

This approach directly targets the non-functional performance requirements by coupling quantifiable quality attributes (latency and availability) with empirical threshold testing, ensuring global system resilience without over-provisioning infrastructure.

View source documentation

Professional Cloud Architect

Define Slo Performance Thresholds Gcp

Professional Cloud Architect

Define Slo Performance Thresholds Gcp

What this solution is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Related questions

Ask Scout