SLO and Error Budget Service  ·  View 13 of 21  ·  Runtime

Critical Flow — Asking for a Verdict

Fourteen messages, and the last one is the design.

Editable source SVG draw.io All views
Release gate Front Door / APIM Verdict API Budget projection SLO registry Key Vault HSM 1. verdict? + workload token 2. validate OIDC, rate limit 3. GET /verdict/checkout 4. policy + version 5. thresholds, gate mode 6. budget state 7. remaining, watermark 8. staleness > ceiling? 9. coverage < 95%? 10. sign document 11. signature 12. exhausted + coverage 99.8% 13. verify signature, apply policy 14. rollback class? exempt 15. unreachable: gate fails static Critical Flow — A Release Asks Whether It Can Ship Fourteen messages, and the last one is the design. The platform never tells the gate to stop; it hands over a signed claim and the gate applies its own declared policy — including the one for the case where this conversation does not happen at all. v 1.0 · owner Reliability Architecture · date 2026-10

Decisions

  • The platform never tells the gate to stop. It returns a signed, typed claim and the gate applies its own declared policy, which keeps the reliability authority off the critical path of everything it governs (ADR-12).
  • Two self-checks run before anything is signed: is the projection stale beyond the ceiling, and is coverage below the floor. Either turns the answer into insufficient-data rather than a figure (ADR-04).
  • The error message is drawn deliberately: the unreachable case is part of the contract, answered by the gate failing static on its cached verdict with a declared staleness ceiling (ADR-13).

Targets

  • Verdict API p99 ≤ 150 ms in-region, ≤ 400 ms cross-region, at 2,000 rps burst for 120 s — assumed.
  • Verdict API availability ≥ 99.95% monthly, measured as successful responses over valid requests per minute — assumed.
  • Signature verification at the gate, so a cached verdict cannot be forged during an outage of this platform.

Risks

  • Fail-static weakens the policy with age. A gate running on an eight-hour-old verdict is enforcing history, and no staleness ceiling is obviously correct (ADR-13).
  • The HSM is on the synchronous path. Signing latency and HSM availability are inside the verdict API's own budget, which is why signatures are short-lived rather than per-request-unique.
◀  Data Model All views Burn-Rate Evaluation  ▶
Solution Architecture v1.0 · Microsoft Azure · Reliability Architecture · 2026-10 · 21 views · 17 architecture decision records13-verdict-request-sequence