Back to Feed
Rollbacks are a lie
The Signal
The speaker argues that simple "rollback" buttons are a dangerous, frequently misunderstood default for stateful software. The core tension is that while users instinctively want an 'undo' for failing systems, the presenter asserts this causes state and schema desynchronization, demanding a 'roll forward' approach to recovery instead.
The Case
- Databases and other persisted information constitute "state" that often cannot be cleanly undone, making a simple revert operation technically unsafe.
- Reversing code versions while leaving upgraded data schemas in place creates a mismatch, where old code blindly attempts to interface with a schema it no longer correctly understands.
- The recommended recovery path for a system failure—such as a bug in 'version 2'—is to ship a 'version 3' containing the fix, rather than attempting a reversion to the prior state.
- The presenter uses schema changes as a diagnostic stress test to show customers why their request for a universal rollback button is fragile, though the speaker's claim that most users have only avoided failure through 'sheer luck' remains an unsupported assertion.
- While the technical risk of code/schema mismatch is documented, the speaker’s demand to 'avoid ever talking about rollback' is an overconfident stance that presumes a single architectural paradigm for all software systems.
The 1 Minute Signal Take
The technical case against simple rollback in stateful systems is strong and well-reasoned. Skip the video; the summary covers the full scope of the operational argument, and the additional color amounts to anecdotal industry posturing.
Tags
Back to Feed