Your platform team wants one shutdown contract for every service on the estate - what do you mandate, and what do you leave to each team?

## Why a single number is the wrong mandate The tempting version of a shutdown standard is "every service gets a sixty-second window". It fails in both directions on the same estate: - The request-serving service finishes everything in under a second and pays a drain pause it never needed sized for someone else. - The reconciliation worker has a four-minute tail and is cut on every deployment, quietly, forever. - The service with an unmeasured drain pause keeps producing transport failures during deploys, and the standard did not address the part that was actually broken. A window is derived from a property of the workload, so it is the one number that cannot be a constant. What *can* be a constant is the shape of the sequence, the requirement to measure, and the evidence that the contract is being met. ## What the contract should mandate 1. **The ordering, exactly.** Leave the routing set; pause; stop accepting new work; finish what was accepted; release claims and leases; exit. This is identical for every workload on any platform, so there is no reason for forty teams to each invent it. 2. **A measured drain pause, not a guessed one.** Require the number to come from an observation - how long requests keep arriving after removal - and require it to be re-taken when the routing layer changes. 3. **A window derived from the service's own tail.** Mandate the formula, not the value: pause plus a high percentile of the longest legitimate unit of work plus a margin. 4. **Its own timeout on long work.** Work that hangs must be bounded by something that is not the forced kill, or the window sizing is corrupted by outages. 5. **Evidence.** A count of units of work cut by the expiry, per service. Without it, a shutdown contract is unfalsifiable: every service claims compliance and the ledger gaps continue. 6. **Shutdown behaviour in the application, not only in platform configuration.** A sequence that depends on the platform running a step on the workload's behalf is not portable across the estate's environments. ## What to leave to each team | Mandated centrally | Left to the service | |---|---| | The order of the steps | What "finish in flight" means for its work | | That the pause is measured | The measured value itself | | The formula for the window | The window's length | | That cut work is counted | How the work is made resumable | | That long work has its own timeout | The timeout's value | The division is deliberate: the platform team owns what is universal and observable, and the service team owns what depends on the shape of its work, because that is the knowledge the platform team does not have and cannot acquire at scale. ## The trade-off you are actually making Every second of drain pause is paid on **every replacement of every replica across the entire estate** - each rollout step, each scale-down, each node replacement. On a large fleet that deploys often, that is a real and continuous cost, and it is the number people try to cut first. Cutting it does not remove the cost; it moves it onto callers as connection failures during deploys, which is strictly worse because it is paid in correctness rather than in seconds. The legitimate ways to buy the time back are all in the work, not in the window: - **Make long units resumable** with checkpoints, so being cut costs a partial replay rather than a lost write. - **Split long units** into pieces that fit comfortably inside a defensible window. - **Move long work off the replacement path** entirely, onto workers whose handover is explicit and whose claim timeouts bound the damage. ## The escape hatch, stated in the standard The contract should say out loud what happens when a service cannot fit: **work whose longest legitimate unit exceeds any window the platform will defend does not belong on the shutdown path.** That sentence is the point of writing a standard at all. It converts a recurring argument about one team's window request into a design conversation about that team's work, and it stops the estate's window drifting upward one exception at a time until every rollout takes an hour. ## How you know it worked Not by an audit of configuration files. By the counter: cut-work events per service per week, trending to zero, with the exceptions being services that have an open design item about resumability. A standard that cannot be checked from telemetry is a document, and a document does not survive the first incident that makes a deadline inconvenient.