Section 2: Fast Enough to Ship, Safe Enough to Sleep - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's assumptions into a contract: functional requirements the platform must demo for smart-reply-v2, and non-functional numbers a test can check, such as evaluation p99 ≤ 50 µs and kill propagation p99 ≤ 5 s. We name what is out of scope and why. Then we frame the tension every later section handles: changes must be fast and safe at once, which the platform achieves by running three clocks at very different speeds.
The clarifications are done, and the interviewer caps the marker: "So what exactly are we committing to?" Two audiences hide in that question. Product teams want speed: flip a flag without waiting for a release train. SRE wants brakes: when something goes wrong at 25%, stop it now and show who started it. And every requirement must be a promise a test could fail. "Kills should be fast" can't fail. "A kill reaches 99% of connected servers within 5 seconds" can.
The Functional Contract
You tie each requirement to the running example so the interviewer can picture the demo:
| Requirement | What it means | The smart-reply-v2 demo |
|---|---|---|
| Flags with variations and rules | Boolean and multivariate flags with ordered rules and a default, per environment | Create smart-reply-v2 in mail-compose, default false |
| Percentage rollouts | Deterministic; raising the percentage only adds people | Dana (bucket 1,234) is out at 1% and 5%, in at 25%, and stays in after that |
| Targeting | Region, tenant, user ring or individual user, composable | Fabrikam employees (Ring 0) first; tenant and region rules stack on top |
| Reusable segments | Named audiences flags reference instead of copying | A "no-preview" tenant list that held Contoso through its pre-launch preview week |
| Rollout plans | Steps with bake times and health gates that advance or pause automatically | Ring 0 (24 h) → 1% → 5% → 25% → 50% → 100% |
| Kill switch | One action, reason required, that overrides every other rule everywhere | On-call presses kill at 14:07:00 on Day 3 |
| Audit and history | Every change versioned, attributed and restorable | "Who moved this to 25%, and when?" |
| Usage and stale-flag reporting | Evaluation counts, last-evaluated time, cleanup prompts | Which services still evaluate it before deletion |
| SDKs and client evaluation | In-process server SDKs; web and mobile get values from an edge service | The web reply chips follow the same rollout |
Two rows draw pushback right away.
Interviewer: "Isn't the kill switch just setting the percentage to zero?"
You: "That sends it through the normal edit path, with approvals and staged propagation, exactly when we can least afford them. A kill is a first-class override: top of the rule order, pre-authorized for on-call, bypassing rollout plans and pending approvals, riding the same stream with priority. It's audited and reversible; un-kill is an ordinary change. Section 8 builds its lane."
Interviewer: "Why must every isEnabled call pass a default? The platform knows the default."
You: "Only if the platform is reachable. No snapshot means the last-known-good copy on disk; no copy means the code default — the one thing we know is present. Section 4 makes this promise part of the SDK's type signature."
Key Insight: Both answers follow one rule: the platform's failures must never become the application's. A flag system that can take down mail-compose is worse than none.
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson