Requirements Scope and Measurable Service Targets

01 The idea

The problem this lesson solves

The prompt says the link service must be fast and highly available.

Prerequisite: earlier lessons introduce the vocabulary and shared examples used here. Follow the module order.

02 Worked example

Follow one worked example

Trace the example in order. Follow the same identities, units and state transitions through the diagram and the events below.

A requirement is reviewable when you can describe the workload and a test that would prove it was violated.

03 The method

Mechanisms decisions and a guided tutorial

Work through the explanation in order, then apply it in the tutorial. Each comparison names a cost as well as a benefit.

Step 1: write the scope box

State what clients can do, what you will deliberately defer, and what success means. For our example: authenticated clients call an API; each client gets at most 3 accepted requests in a fixed 60-second window across all application instances. Excess requests receive HTTP 429. Assume a single region, 100 active clients, and a target of 10 milliseconds added latency at the 99th percentile. These are exercise assumptions. Abuse detection, billing and global fairness are outside this first design.

Make non-functional targets measurable

‘Fast’ is not a test. ‘99 percent of decisions finish within 10 milliseconds at 100 requests per second’ is testable. Latency is the time for one request; throughput is completed requests per unit time. Availability describes successful service over a defined period. If you use a time-based target, 99.9 percent availability permits 43.2 minutes of downtime in a 30-day month: 30 × 24 × 60 × 0.001. A request-based service-level objective measures successful requests instead, so always state the denominator.

Write the workload beside the target

“Responses below 200 ms” needs a scope. Is it an average, a percentile or every request? Is it measured at the browser, the gateway or the application? Does it include failed requests? Write these boundaries before comparing architectures.

For a redirect service, an example objective is 99 percent of valid redirect requests completed within 200 ms at the gateway under 500 requests per second in one region. The numbers are exercise inputs. A monitoring query and a load-test report can now assess that sentence. Without the boundary, two teams may both report 200 ms while measuring different parts of the request.

Separate correctness from service quality

“One active booking for each seat and show” is an invariant. “The booking endpoint responds within 500 ms” is a latency objective. A fast response that books the wrong seat is not a successful operation. Define a success event using both protocol and business meaning.

Write an in-scope list and an out-of-scope list. For a first short-link design, create and redirect can be in scope while analytics and custom domains are deferred. Scope controls the rest of the discussion: a globally replicated analytics pipeline does not solve a requirement that was deliberately excluded.

Translate availability into a budget carefully

A time-based 99.9 percent objective for thirty days permits 43.2 minutes unavailable. A request-based objective counts good requests divided by eligible requests. These can disagree when traffic is uneven: a short outage at the busiest moment may affect more requests than a longer quiet-period outage.

Define which requests are eligible and what constitutes a good response. Client mistakes may be excluded, but a server-side 500 must not disappear from the denominator merely because it makes the dashboard less attractive. Choose a window and state how partial failures are counted before designing alerts.

Guided tutorial

1. Draft a requirements table

Use columns requirement, measurement boundary, test and assumption.

2. Inspect one percentile

Sort 100 example latency values; explain which observation represents the chosen percentile convention.

3. Compare denominators

Describe a quiet-hour and a peak-hour outage with equal duration.

4. Resolve an ambiguity

Decide whether a database timeout is a bad eligible request in your service objective.

scope: create links, follow links
workload: 500 redirect requests/second, one region
latency: p99 below 200 ms, measured at the gateway
availability: good / eligible requests >= 0.999 over 30 days
correctness: a successful create has one durable unique code

04 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

05 Where & why

Check the primary references

Use official references for protocol and implementation details. The questions here are teaching prompts.

06 Interview questions

Explain the reasoning out loud

Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.

07 Practice problems

Practice a new case

Solve the new cases before revealing hints. Complete worked solutions follow the set.

Worked solutions