Deployment Strategies

Cover this or you fail the question

• Recreate: stop the old version, start the new one. Simple, no version mixing, and it has downtime. Legitimate for internal tools and for changes that genuinely cannot tolerate two versions running at once.
• Rolling: replace instances in batches until all are updated. No downtime and no extra infrastructure, but both versions serve traffic simultaneously for the duration, and rollback means rolling back through the same process rather than flipping a switch.
• Blue-green: run a full second environment with the new version, verify it, then switch all traffic at once. Rollback is switching back and is close to instant, which is its real selling point. It costs a second environment and needs a plan for data written during the switch.
• Canary: route a small percentage of traffic to the new version, watch error rates and latency, then increase gradually or abort. It limits how many users are exposed to a bad release, and it requires enough traffic for the sample to be meaningful and good enough metrics to make the decision on.

Cover this or you fail the question

• A/B testing routes traffic to variants to measure which produces a better product outcome, and runs for as long as it takes to reach statistical significance.
• A canary looks mechanically similar and asks a different question: is this release safe. It is measured in technical signals, it runs for minutes or hours, and its success condition is nothing getting worse.
• Saying this distinction out loud is worth doing, because the two are frequently listed side by side as if interchangeable and separating them demonstrates you understand the purpose rather than the mechanism.

What separates a solid answer

• A feature flag lets code be deployed to production while the feature stays off, so deploying stops being the risky event and enabling the feature becomes the controlled one.
• This is what makes trunk-based development with frequent small deployments workable, and it means turning a feature off is instant and does not require a rollback at all.
• It also changes the strategy calculus: with flags, a rolling deployment is adequate for most changes, because the risky part is not the new binary but the new behaviour, which is controlled separately.
• The honest cost is that flags accumulate. Every flag is a branch in the code and untested combinations multiply, so flags need owners and expiry dates or the codebase becomes a maze of conditions nobody dares remove.

What separates a solid answer

• Application rollback is easy; schema rollback frequently is not, and this is the point that separates candidates who have done deployments from those who have read about them.
• The technique is expand and contract: make additive changes first, deploy code that works with both old and new shapes, migrate the data, and only remove the old structure after the new code is proven and rollback is no longer needed.
• That means never renaming or dropping a column in the same release that stops using it. Add the new column, write to both, backfill, switch reads, and drop the old one a release later.
• During any strategy where two versions run at once — rolling and canary always, blue-green during the switch — both versions share one database, so the schema must be compatible with both. This is what people mean when they say the deployment strategy constrains the migration strategy.

Common trap: Describing an instant blue-green rollback without addressing data written by the new version. If the new version wrote rows in a shape the old one cannot read, switching back is not clean and the plan needs to say what happens to them.

What separates a solid answer

• Ask what the blast radius of a bad release is, and how quickly it can be undone. Those two answers pick the strategy more reliably than any general preference.
• High traffic and high risk favours canary, because a small percentage of a large number is still enough signal to decide, and exposure is limited while you gather it.
• A requirement for instant, certain rollback favours blue-green, and the second environment is the price of that certainty.
• Low traffic makes canary weak, because a small percentage of a small number is not enough to detect a regression before it affects everyone anyway — a real limitation worth naming.
• Rolling is the reasonable default for ordinary changes, particularly combined with feature flags carrying the behavioural risk.

The senior signal

• A canary is only as good as the criteria for promoting or aborting it. Those should be defined in advance as thresholds on error rate, latency and a business metric, and evaluated automatically rather than by someone watching a dashboard.
• Automatic rollback on threshold breach is what makes the strategy work at scale, because a human deciding is slow and reluctant, and reluctance during a bad release is expensive.
• The metrics compared should be the new version against the current one over the same window, not against a historical baseline, since traffic patterns move for reasons unrelated to the release.
• The mature position is that deployment strategy is one part of reducing change risk, and the others matter as much: small frequent changes are safer than large infrequent ones, and a system where deploying is routine and boring has fewer incidents than one where releases are rare, large and consequently frightening.