Canary Deploy Patterns
Ship to a fraction of users, measure, then roll forward or back — without waking up the whole org.
Traffic splitting
Route 5–10% of production traffic to the new revision via weighted DNS, load-balancer rules, or service-mesh sidecar config. Keep the stable revision serving the rest.
Observation window
Let the canary bake for 15–60 minutes. Compare error rate, p99 latency, CPU saturation, and crash-loop counters against the baseline. Prometheus + Grafana dashboards pinned side-by-side work well here.
Automatic rollback
Wire a circuit breaker: if error budget burn exceeds threshold during the window, shift all traffic back to stable and halt the pipeline. No human-in-the-loop required at 3 AM.
Progressive promotion
After the first window passes, step traffic to 25%, then 50%, then 100%. Each step resets the observation clock. Full rollout should complete within a few hours.
Feature-flag canaries
Deploy dark and toggle on per-tenant or per-region. Lets you decouple code ship from feature activation — useful when the payload touches shared database schemas.
Meridian tip: Pair canary deploys with feature flags so you can disable the new path without a full rollback.