Safe Deployment and Rollback Strategies Questions

Direct answer
A strong answer here follows STAR: what tipped you off that something was wrong, what you actually did to execute the rollback, and what changed afterward so the same failure mode doesn't recur. The interviewer is listening for concrete detection signals and concrete actions, not a vague "we noticed issues and rolled back."

Structured elaboration

• Situation/Task: name the service, the scale (traffic volume matters for how fast things degraded), and what the deploy changed.
• Action - detection: was it a dashboard alert, a customer report, a synthetic check? Specificity here (a named metric crossing a named threshold) is what separates a real story from a generic one.
• Action - execution: what commands or automation did you actually run? Redeploy previous image tag, flip a feature flag, revert a config? Did you have to coordinate a database rollback too, or was code-only sufficient?
• Action - safety checks: how did you confirm the rollback itself was safe before running it (was there a schema dependency you had to check first)?
• Result: how long did it take from detection to resolution, and what was the actual customer impact?
• Follow-up: what changed afterward: a new automated rollback trigger, a canary gate that would have caught it earlier, a runbook that didn't exist before?

Worked example
"We shipped a change to our checkout service that introduced a null-pointer path under a rare cart configuration. Fifteen minutes after full rollout, our error-rate alert fired at 3% (baseline 0.1%). I confirmed via the dashboard the spike started at the deploy timestamp, then ran our rollback script to redeploy the previous image tag, which took about ninety seconds including health-check verification. Error rate returned to baseline within two minutes of the redeploy completing. Afterward we added that cart configuration as an explicit test case and lowered our canary's automated error-rate threshold so a similar regression would be caught at 1% traffic instead of 100%."

Trade-offs and pitfalls
A common weak answer stops at "we rolled back and it was fixed" without naming a detection signal or a concrete command, which reads as secondhand rather than lived experience. Another common gap is skipping the "what changed afterward" beat entirely, which is often what the interviewer is most interested in, since it signals whether you learn from incidents systemically or just fight fires one at a time.

Direct answer
The recreate deployment strategy tears down every instance of the old version before starting any instance of the new one, accepting a period of full downtime in exchange for the simplest possible mental model: at any given moment, either all-old or all-new is running, never a mix.

Structured elaboration
Teams still choose recreate, despite the downtime, when:

• Mixed-version compatibility is genuinely hard or unsafe to reason about: if old and new code can't safely coexist even briefly (a breaking, non-backward-compatible change with no feasible way to make it compatible for a transition window), recreate avoids ever creating that mixed-version state at all, at the cost of downtime instead.
• The service can tolerate a maintenance window: an internal tool, a batch-processing system, or a service with well-understood low-traffic periods can schedule the downtime somewhere it genuinely doesn't matter much, making the simplicity worth the (planned, contained) cost.
• Resource constraints: environments without spare capacity for even a small surge (an embedded system, a resource-constrained edge deployment, a small on-premises cluster with no slack) may not have room to run old and new simultaneously even briefly, making recreate the only option that fits the available resources.
• Simplicity as a deliberate choice for a low-stakes service: not every service justifies the operational complexity of a rolling update or canary; a low-traffic internal dashboard might reasonably just accept a 30-second restart rather than investing in zero-downtime tooling for something that doesn't need it.

Worked example
A nightly batch-processing job that only runs during a defined off-peak window: recreate is not just acceptable but arguably the RIGHT choice, since there's no live traffic to protect during that window anyway, and the operational simplicity (no need to reason about version-skew compatibility, no readiness-probe tuning) reduces real complexity for no actual downside given the service's usage pattern.

Trade-offs and pitfalls
The common mistake is defaulting to recreate purely out of inertia or unfamiliarity with rolling/canary patterns, on a service that actually DOES have meaningful live traffic and would benefit from a more careful strategy; recreate should be a deliberate choice matched to a specific service's tolerance for downtime, not the path of least resistance for every service regardless of its actual traffic pattern.

Direct answer
A canary deployment ships a new version to a small slice of traffic first, watches it closely against the stable version, and only widens exposure if it looks healthy; if it doesn't, you pull the plug on a small fraction of users instead of everyone.

Structured elaboration

1. Initial slice: route a small percentage of traffic, often 1-5%, to the new version while the rest continues on the stable version.
2. Observe: compare metrics between the canary and the stable baseline over the SAME time window, not the canary against yesterday's numbers, since traffic patterns shift by time of day.
3. Decide: if the canary's metrics stay within an acceptable band of the baseline for long enough, promote to a larger percentage; if they degrade, roll back the canary slice.
4. Ramp: repeat at increasing percentages (for example 5% -> 25% -> 100%) rather than jumping straight to full traffic, since a problem that only shows up under real production load or a particular traffic mix might not surface at 1%.
5. Promote or rollback trigger: could be a manual decision from a dashboard, or automated based on a metric threshold; either way it needs an explicit, pre-agreed criterion, not "it felt fine."

Worked example
A checkout service canaries a payment-processing change at 2% of traffic for 30 minutes. Error rate on the canary stays at 0.15% versus the stable version's 0.12%, well within the agreed 0.5% absolute-difference tolerance, so the team promotes to 25% for another 30 minutes, then to 100%.

Trade-offs and pitfalls
Canary buys you a much smaller blast radius than a straight rollout, but it's slower to reach full deployment and needs enough traffic volume for the canary slice to be statistically meaningful; a low-traffic service at 1% might only get a handful of requests, which isn't enough to detect a real but modest regression. The common mistake is treating a clean canary window as proof of correctness rather than as reduced risk: rare edge cases and slow-building problems (a memory leak, a cache-warming issue) can still slip through a short canary window.

Direct answer
A rolling update replaces old-version instances with new-version ones gradually, a few at a time, so the service stays available with a mix of old and new versions running simultaneously during the transition. A recreate deployment, by contrast, terminates ALL old instances first and only then starts the new ones, which means a period of full downtime but avoids ever running mixed versions.

Structured elaboration
For a stateless microservice in Kubernetes, a rolling update:

1. Kubernetes creates a batch of new-version pods (controlled by maxSurge, how many extra pods above the target replica count are allowed).
2. Waits for those new pods to pass their readiness probe before routing traffic to them.
3. Terminates an equivalent batch of old-version pods (controlled by maxUnavailable, how many pods can be down at once).
4. Repeats until all pods are on the new version.

Common failure modes to watch for during a rollout:

• Readiness probe misconfigured too loosely: traffic gets routed to a pod that's technically "ready" but not actually able to serve correctly yet (cache not warmed, connection pool not established).
• Version skew during the mixed-version window: old and new pods running simultaneously both talk to the same downstream dependencies (shared database, shared cache), so if the new version isn't backward-compatible with what the old version expects, you get intermittent failures purely from which version happened to handle a given request.
• Resource exhaustion from surge: if maxSurge allows too many extra pods at once relative to available cluster capacity, new pods can fail to schedule, stalling the rollout partway.
• A bad new version rolling out gradually still affects a growing fraction of traffic before anyone notices, unlike blue-green where the bad version is fully isolated until an explicit cutover.

Worked example
A 20-replica deployment with maxSurge: 25% and maxUnavailable: 25% creates up to 5 extra pods (25 total temporarily) while taking down up to 5 old pods at a time, cycling through until all 20 are on the new version. If the new version has a subtle bug that only manifests under a specific downstream response, roughly a quarter of traffic is exposed to it at any point mid-rollout, growing toward 100% as the rollout proceeds, unless something halts it.

Trade-offs and pitfalls
Rolling update avoids downtime and extra infrastructure cost (no duplicate fleet, unlike blue-green) but accepts a mixed-version window where compatibility between old and new has to hold, and it doesn't isolate a bad release the way canary or blue-green does; it just gradually replaces capacity regardless of whether the new version is actually healthy, UNLESS combined with a readiness-probe-based or metrics-based halt condition.

Direct answer
A full rollback reverts every service or component involved in a release back to its previous version; a partial rollback reverts only some of them, leaving others on the new version. You choose partial when only some of the changed components are actually implicated in the problem and reverting the rest would be unnecessary churn or would itself introduce risk (for example, if a later component now depends on an earlier one's new behavior).

Structured elaboration

• When full rollback makes sense: a single service deployed a bad change, or several services were released together as one coupled unit where partial reversion would leave them in an inconsistent, untested combination.
• When partial makes sense: a coordinated multi-service release where only ONE service's new version is misbehaving, and the others are backward-compatible enough to keep running against either the old or new version of the problem service.
• Risk in partial rollback: you have to be confident the services you're leaving on the new version don't assume the now-reverted service's new behavior; if they do, a partial rollback trades one outage for a different, subtler one.

Worked example
Full: three tightly coupled microservices (auth, session, and API-gateway) deploy together as one release because the API gateway's new version assumes session's new token format; a bug anywhere means reverting all three together, since a partial revert would leave a token-format mismatch between them.
Partial: a release touches a recommendations service and a completely independent notifications service in the same deploy window purely for scheduling convenience; if only recommendations regresses, rolling back just that service and leaving notifications on its (unrelated, unaffected) new version is the right call, since reverting notifications too would be pure unnecessary churn.

Trade-offs and pitfalls
Partial rollback is faster and less disruptive when it's safe, but the judgment call of "is it actually safe to leave X on the new version" is exactly where mistakes happen; teams that don't explicitly map service dependencies before a coordinated release often discover the hard way, mid-incident, that two "independent" services weren't as independent as assumed.