Replacing a model everywhere at once means finding out about its failures from your users.
A canary release sends a small share of live traffic to the new version and watches the metrics.
If the numbers hold, the share is raised gradually; if not, the traffic is moved back.
A shadow deployment sends a copy of every request to the new version and discards its output.
Shadow proves it works on real traffic without risking anyone, but never tests the user's reaction.
Offline evaluation tells you a new model is better on your test set.
It cannot tell you how it behaves on live traffic, under real load, with real inputs.
Two deployment patterns close that gap, and they answer different questions.
A canary release routes a small fraction of production traffic to the new version.
One or two per cent is a usual starting point, held long enough to gather meaningful data.
Error rates, latency and quality signals are compared between the two groups.
If everything holds, the share is increased in steps until the old version is retired.
If anything degrades, traffic is shifted back, and the blast radius was one per cent of users.
A shadow deployment takes a different approach: every request goes to both versions.
The new version's response is logged and compared and then thrown away.
Users only ever see the old version, so the risk to them is zero.
That makes shadow the right choice when the new version might be badly wrong.
It exercises the real input distribution, including the strange requests no test set contains.
Its limits are cost, since you pay for every request twice, and side effects, which must be disabled.
It also cannot measure user reaction, so shadow first to prove correctness, then canary to prove value.
One question on this card. Every option explains itself once you pick, right or wrong.
22 concepts in this module, then a graded test with every answer explained.