gw-12 — Analysis & Capstone Exercise
This capstone is a method, not a new protocol. The "analysis" is a written migration plan you produce, plus a runnable exercise that exercises the ladder against the labs you built.
The capstone exercise
Pick one migration and take it through the full ladder using your own gw-* implementations:
Migrate origin calls from "connect-per-request" (gw-01) to "pooled + subsetted" (gw-04) across a simulated fleet — with zero dropped requests and a measured churn reduction — using shadow → canary → ramp → soak, gated by the gw-11 metrics, driven by the gw-08 control plane, with instant rollback.
Deliverables:
-
A design doc (the artifact a "5" is judged on). Sections:
- Goal / non-goals — "cut origin connection churn ≥5×; do not change request semantics."
- Current state / target state — gw-01 path → gw-04 path.
- Alternatives considered — h2-only origins? bigger pools? — and why subsetting+pools.
- Rollout plan — the ladder, with per-rung success criteria.
- Rollback plan — flag flip; old
Transportkept warm. - Blast-radius staging — by simulated region/cluster/node group.
- Risks accepted — e.g. per-loop pools raise idle connections; subset size vs resilience headroom.
- Observability — exactly which gw-11 metrics gate each rung.
- Stakeholders & comms — who's affected, what they must do, the timeline and deprecation date.
-
A runnable rollout harness that:
- routes a configurable % of traffic to the new path (gw-03 routing + gw-08 flag push);
- shadows 100% to the new path while serving from the old, and diffs responses (status/latency) — zero user risk;
- runs an automated canary check: compare new-vs-old RED metrics (gw-11); auto-rollback if the canary's error rate or p99 regresses beyond a threshold;
- ramps 1% → 5% → 25% → 100% with a soak at each rung;
- proves the churn drop (gw-04
connections.created.rate) with no increase in 5xx through the whole ramp.
What "done" looks like
- A before/after plot: churn collapses (gw-04), p99 and error rate unchanged across the ramp (gw-11).
- A demonstrated instant rollback: flip the flag mid-ramp, traffic returns to the old path with no errors.
- A design doc that someone could actually run a review against.
Leadership rubric (how a "5" is assessed on this)
| Dimension | Evidence in your capstone |
|---|---|
| Ownership | you scoped, built, rolled out, and verified end-to-end |
| Judgment | reversible-by-default, staged blast radius, data-gated decisions |
| Risk management | shadow before serve; warm rollback; soak before decommission |
| Communication | a design doc that names non-goals, alternatives, and accepted risks |
| Stakeholder alignment | a comms plan + deprecation timeline, adoption-by-pull |
| Mentorship | a slice scoped for a junior to own, with a review plan |
| Data discipline | every promote/rollback decision tied to a gw-11 metric |
Tradeoffs worth flagging (the senior reflexes)
- Speed vs safety. Healthy error budget (gw-11) buys faster ramps; a burning budget means slow down or freeze. The budget is the dial.
- Two code paths are a tax. Every rung you don't finish leaves dual paths to maintain; plan the decommission, don't let it rot.
- Shadow has limits. It validates reads/idempotent paths cleanly; for writes you need careful diffing or a separate strategy (the mirrored write must not cause real side effects).
- Stakeholders are the critical path. The technical rollout is often ready before the partner teams are; the migration leader's real job is unblocking them.
What production adds beyond this exercise
- Statistical automated canary analysis (Kayenta-style) rather than a threshold check.
- Region/cell-aware staged rollout with PodDisruptionBudgets and surge control (gw-09) so you never drain too much at once.
- Org tooling: migration dashboards, partner self-service, automated deprecation tracking.
- A real rollback rehearsal ("game day") before the ramp, not just a rollback plan on paper.