Canary Release
Send 5% of users to the new release first; expand only while error rate stays healthy, and return to the stable release on anomaly.
Send 5% of users to the new release first; expand only while error rate stays healthy, and return to the stable release on anomaly.
Checkout errors0.2%
Checkout errorsNo traffic
↳v1 serves every request; v2 is ready but has no real users yet.
Limit possible impact to a small scope: An all-at-once checkout release exposes every request to unknown defects. Giving v2 5% of traffic while verified v1 keeps the other requests tests the new release under real conditions without immediately widening impact.
Let agreed signals decide the next step: Define an observation period, error or latency threshold, and return action before release. Expand only while signals are healthy; stop and restore the stable version above the threshold. A quiet small sample still cannot prove every path is correct.
Canary checkout v2 at 5% traffic and observe checkout error rate and latency for 15 minutes. Expand only while error rate stays below 2%; above the threshold, stop and return traffic to v1. Report actual traffic and metrics for both versions.