Transcript Organizer

Experiment 06 · Teaching kit

Teaching saturation as a systems skill

A 75-minute lesson with objectives, exercises, misconceptions, retrieval questions and a source-checked answer key.

Learning objectives

By the end of 75 minutes, learners can:

  1. Distinguish utilization, saturation and failure.
  2. Trace amplification through retries, fan-out, logging and automated recovery.
  3. Explain base capacity versus graceful extensibility.
  4. Propose one safety valve and evaluate its tradeoff.
  5. Describe incident evidence that preserves responder reasoning.

Lesson sequence

MinutesActivityInstructor moveEvidence of learning
0–8Boundary predictionAsk: "What fails first in a healthy service under 4× demand?"Learners name a finite resource and observable queue.
8–20Mini-lesson: saturationUse Frank–Starling and competence-envelope frames.Learners distinguish a boundary from an error.
20–35Feedback-loop tracingGive the retry scenario below.Groups label reinforcing edges.
35–50Incident comparisonAssign Bluesky, Slack or Waymo.Groups identify demand, finite path and adaptation.
50–65Control designRequire one guardrail and reversal signal.Proposals state what the control consumes.
65–75Retrieval quizUse questions before revealing answers.At least 6/8 with corrected reasoning.
Frank-Starling curve used in the talk as a saturation analogy
Prompt: where does "more input" stop producing proportional output, and what is observable before collapse?

Exercise A · Complete the loop

A dependencyʼs P99 rises above the caller timeout. Clients retry twice. Workers remain occupied while waiting. Autoscaling adds callers.

  1. Draw four nodes and arrows that make the reinforcing loop explicit.
  2. Mark the first quantity that queues.
  3. Choose one edge to cut. State a user-visible cost.
  4. Name a metric that can improve while the incident worsens.

Exercise B · Classify the response

For each, decide whether it expands the base envelope, creates optionality, activates adaptive capacity, or does more than one:

  • Add headroom to a connection pool after load testing.
  • Give incident commanders a tested, expiring traffic-block control.
  • Teach responders how to isolate one tenant without redeploying.
  • Write a postmortem that preserves abandoned hypotheses and red herrings.

Quiz

  1. Can a resource be saturated below 100% reported utilization? Explain.
  2. Why can a bounded queue be a safety feature?
  3. What made Slackʼs autoscaling response relevant to saturation?
  4. What is the risk of logging every error during a failure?
  5. How does a slow leak hide behind deployment?
  6. What separates a feature flag from usable adaptive capacity?
  7. Why does the talk resist "prevent every incident" as a learning strategy?
  8. What should a postmortem preserve besides corrective actions?

Open the instructor answer key.