A city wants the new 311 web UI seen by only about 5% of citizen traffic before a wider rollout. Which delivery technique fits?
Select an answer to reveal the explanation.
Short Explanation
You can use a canary release to let a small slice of citizens try the new 311 UI first, then widen the rollout if the signals look healthy. Replacing every node at once, upgrading an unreachable kiosk, or deploying to everyone after a local build doesn’t provide that gradual exposure.
Full Explanation
A canary release routes a small percentage of live traffic to the new version before a wider rollout. For a city 311 web UI intended for about 5% of citizen traffic initially, this technique exposes a limited slice, lets you watch error and latency signals, and supports expansion if the release is healthy. Progressive exposure reduces the blast radius of a citizen-facing change compared with an immediate full cut. Replacing every 311 node worldwide in one unmonitored big-bang cut fails because it sends the change everywhere at once, without limiting traffic or allowing a gradual rollout. Upgrading only a single offline kiosk that no citizen can reach fails because it receives no live citizen traffic and cannot provide a production signal about the UI. Deploying the UI to all citizen traffic after validating it with a successful local build also fails: a local build does not expose the new version to a small production traffic slice, and sending everyone to it skips progressive exposure. Exam caveat: a canary is defined by a limited share of live traffic, not merely by testing the software somewhere; immediate exposure to all traffic is not a canary. Practical check: configure a 5% weight for the new 311 UI, verify metrics and logs show only a minority of citizen sessions on it, and promote or roll back based on release gates. Confirm that the majority of sessions still reach the stable version during the canary window.