Forward Fix

Rollback is the default advice and it is usually right, but it is not always available, and pretending otherwise produces incidents where a team burns twenty minutes discovering that the revert does not work.

Rollback stops being possible once the new version has done something irreversible: applied a non-backward-compatible migration, published events in a new format that consumers have already processed, written data the old code cannot parse, or drained a queue in a way that cannot be replayed. It is also unavailable when the previous version has a worse problem, such as an expired certificate or a since-revoked credential.

Forward fix is therefore not merely the impatient option; it is the only option in those cases, and the architecture decides which world you live in. Backward-compatible schema changes and versioned event payloads keep rollback available, and that availability is worth designing for deliberately.

The rule during an incident: choose the path with the shorter and better-understood recovery, and decide within minutes rather than debating. A rollback you have practised beats a forward fix you are inventing at 2 AM.