Apply the pattern to your own service

Scenario

Your team ships a read-heavy API or a page that fans out to several HTTP calls. In reviews, someone asks: “Are we sure this stays fast enough when traffic is normal Monday morning, not just on a developer laptop?” You want the same observe, set, validate loop you used on QuickPizza, but the URL, auth, and risk profile are yours.

Tradeoffs to decide explicitly

What “good” looks like

• One primary route in scope first (expand later). Everyone agrees which URL or user journey the gate protects.
• Steady-state window long enough that p95 and error rate stop jumping run to run.
• Checks assert something the business cares about (status, a required field), not only “200 OK.”
• Thresholds came from numbers you observed, not a round number someone guessed.
• Flaky gate = worse than no gate; if CI fails randomly, fix the profile or thresholds before enforcing.

Transfer exercise (15 to 30 minutes)

Do this once on a non-production URL your team owns:

1. Pick the target: one critical GET or POST and a success condition you can assert in a check.
2. Copy the QuickPizza script shape: options, default function, at least one http call and a sleep that matches realistic pacing.
3. Run once without thresholds at a modest VU count; note p95, http_req_failed, and throughput from the summary (or Grafana Cloud k6).
4. Set thresholds with headroom on p95 and a cap on error rate; re-run until two consecutive runs agree.
5. Write one line in your README or ticket: what the gate protects and what you would do if it fails.

That is enough to prove the skill transferred. When you expand, use your internal standards and the documentation on the Where to go next slide.