A rollback process reverts a production deployment to the last known-good version quickly and safely when a critical bug surfaces, minimizing user impact while a proper fix is developed.
Key Points: • Deployment tooling (CI/CD pipeline, Kubernetes rollout history, blue-green switch) should support a one-command or one-click rollback to the previous version. • Version control and immutable artifact storage ensure the "last known good" build can always be redeployed exactly as it was. • Continuous monitoring and alerting are what typically trigger the rollback decision quickly, before the issue snowballs. • Database migrations complicate rollback if the new version introduced a schema change -- migrations should be written to be backward-compatible where possible. • A postmortem after the rollback identifies the root cause and prevents the same class of bug from reaching production again.
Example: If a Kubernetes deployment introduces a critical bug, kubectl rollout undo reverts the deployment to the previous ReplicaSet within seconds, restoring the last stable version while the team investigates the root cause offline.
Interview Tip: A concise interview answer is:
"I'd rely on the deployment tooling's built-in rollback -- whether that's kubectl rollout undo, redeploying the previous artifact from the repository, or flipping back to the blue environment in a blue-green setup. Monitoring and alerting are what trigger that decision fast, and I'd make sure database migrations are backward-compatible so a rollback doesn't break on schema mismatches."