What is Rollback?
A rollback returns a system to a previous known good state after a change causes problems. When a recent reversible change caused the problem, rollback is often one of the fastest mitigations.
How rollback works
The simplest form redeploys the previous artifact version. Faster forms avoid a deploy cycle entirely: blue-green switches traffic back to the environment still running the old version, and feature flags disable the new behavior without touching what is deployed.
The essential property is speed and reliability, not elegance. A rollback path that takes twenty minutes and occasionally fails is not a mitigation you can depend on during an incident, which is precisely when it will be used.
Why rollback matters
Rollback works without requiring you to understand what went wrong, which is what makes it valuable under pressure.
- Cause independent: reverting works whether or not the defect is understood.
- Fast mitigation: user impact stops before diagnosis begins.
- Reduced pressure: the fix can then be developed calmly rather than in an emergency.
- Deploy confidence: a trustworthy rollback path makes teams willing to ship more often.
Limits and things that cannot be rolled back
Database migrations are the hard case. Reverting application code does not revert a schema change, and a rollback into an incompatible schema fails or corrupts data. Expand and contract migration patterns exist specifically to keep rollback possible across schema changes.
Some effects are irreversible regardless. Emails sent, payments processed, external webhooks delivered, and data deleted cannot be undone by redeploying. Rollback restores code, not consequences, and changes that produce external side effects need a different safety strategy.
Rollback vs roll forward
Rolling forward means fixing the defect and deploying the corrected version rather than reverting. It is appropriate when the previous version has its own serious problem, when the fix is trivial and well understood, or when rollback is genuinely impossible.
Rollback is the default under pressure because it is faster and lower risk. Rolling forward requires writing correct code during an incident, and code written in that state is more likely to introduce a second problem. The reasonable rule is to roll back first and roll forward once the situation is calm.
Key takeaways
- Rollback mitigates without requiring the cause to be understood, which is why it is the default first action.
- The path must be fast and reliable, since it is used exclusively under pressure.
- Schema changes break naive rollback, which is why expand and contract migration patterns exist.
- External side effects such as sent emails and processed payments cannot be reversed by redeploying.