What Rollback Strategies Would You Use in a Deployment Pipeline?
Learn layered rollback strategies for deployments — app-layer, database-layer, and feature flags — with real Kubernetes examples for interviews.
Expected Interview Answer
A solid rollback strategy combines fast, automated reversal at the deployment layer — redeploying the previous known-good artifact or flipping a router back to the prior environment — with careful handling of stateful changes like database migrations, so a failed release can be undone in minutes without corrupting data.
At the application layer, the fastest rollback is redeploying the last known-good image tag or, in a blue-green setup, switching the load balancer back to the still-running previous environment, which typically takes seconds. Kubernetes supports this natively via `kubectl rollout undo`, which reverts a Deployment to its previous ReplicaSet revision. The harder part is state: rollbacks are only safe when backward-compatible, meaning database schema changes must be additive and non-breaking until the old code path is fully retired, otherwise rolling back the app while a migration has already run leaves the two out of sync. Feature flags add a third, even faster lever — disabling a flag reverts behavior instantly without any redeploy at all, which is often preferable to a full rollback for isolating a single bad feature.
- Minimizes downtime and user impact when a release fails
- Separates fast app-layer rollback from slower state-layer rollback
- Feature flags allow instant behavior reversal without redeploying
- Builds team confidence to ship more frequently
AI Mentor Explanation
A rollback strategy is like a captain having a pre-agreed plan to bring back the previous bowler immediately if a tactical change backfires mid-over, rather than debating field settings while runs are being conceded. Swapping the bowler back is fast, but if the wicketkeeper has already changed gloves for the new bowler’s style, that change needs its own careful reversal too. A team that rehearses this switch beforehand reacts in seconds, not overs. The goal is limiting damage the moment a decision proves wrong.
Step-by-Step Explanation
Step 1
Keep the previous artifact deployable
Retain the last known-good container image or ReplicaSet so a revert needs no rebuild.
Step 2
Trigger the fast app-layer rollback
Use `kubectl rollout undo`, redeploy the prior tag, or flip the router back in a blue-green setup.
Step 3
Handle state separately
Confirm database migrations were backward-compatible; if not, run a compensating migration.
Step 4
Use feature flags for instant reversal
Disable the flag gating the new behavior for a sub-second fix without a full redeploy.
What Interviewer Expects
- Understanding that app rollback and data rollback are different problems
- Awareness that migrations must be backward-compatible to allow safe rollback
- Knowledge of concrete tooling like kubectl rollout undo or blue-green router flips
- Recognition that feature flags are the fastest rollback lever available
Common Mistakes
- Assuming a code rollback also reverts already-run database migrations
- Not testing the rollback path before it is needed in production
- Treating rollback as a single universal action instead of layered ones
- Ignoring in-flight requests or sessions that started on the reverted version
Best Answer (HR Friendly)
“I like to think about rollback in layers. The fastest layer is flipping a feature flag off, which fixes things in seconds with no redeploy. Next fastest is redeploying the previous known-good build. The trickiest layer is data — I always make sure database changes are backward-compatible so that a code rollback never leaves the database out of sync with the app.”
Code Example
# Check rollout history for a Deployment
kubectl rollout history deployment/myapp
# Roll back to the immediately previous revision
kubectl rollout undo deployment/myapp
# Roll back to a specific earlier revision
kubectl rollout undo deployment/myapp --to-revision=3
# Watch rollout status until it stabilizes
kubectl rollout status deployment/myappFollow-up Questions
- How do you make a database migration safe to roll back from?
- What is the difference between rolling back and rolling forward with a fix?
- How do feature flags reduce the need for full deployment rollbacks?
- How would you test a rollback plan before a risky release?
MCQ Practice
1. What is the fastest way to revert a single bad feature without a full redeploy?
Feature flags allow instant behavior reversal at runtime, without needing to rebuild or redeploy any code.
2. Why can a code rollback still leave a system broken after a bad release?
If the migration was not backward-compatible, reverting the app code alone leaves the database schema mismatched with what the old code expects.
3. What command reverts a Kubernetes Deployment to its previous ReplicaSet revision?
`kubectl rollout undo` reverts a Deployment to the previous revision recorded in its rollout history.
Flash Cards
Fastest rollback lever? — Disabling a feature flag — reverts behavior instantly with no redeploy.
Command to revert a Kubernetes Deployment? — `kubectl rollout undo deployment/<name>`.
Why must migrations be backward-compatible? — So a code rollback never leaves the database schema out of sync with the older app version.
What is layered rollback? — Treating app-layer rollback, state-layer rollback, and flag-layer rollback as separate, sequenced actions.