Ask HN: Do you bother making state changes reversible?
I’m trying to understand how people handle changes to real system state. In many projects, once something writes to a DB or config, the previous state is effectively gone unless you planned for it upfront.
I haven’t personally dealt with large-scale failures here, but with more automation and AI writing state directly, it feels like reversibility matters more.
Curious whether teams actively design for rollback, or mostly rely on backups and manual fixes. There are forms of state that are reversible: essentially, you store read-only events instead of writing to existing state. The main disadvantages are more complexity and performance issues. Examples: - Event sourcing: https://youtu.be/8JKjvY4etTY - CRDT - At the DB layer: https://www.datomic.com - You can also do it at the code level (but this is more like keeping copies of the old state): https://immerjs.github.io/immer Check out Nix and NixOS. NixOS is designed to keep a record on system changes, and rollbacks are easy (atleast regarding configuration changes).