In Defense of the Unrecoverable: Why Some Data Should Be Allowed to Die
Our industry is built on a bedrock of caution. We are taught, from our first fumbling encounters with a terminal, that data is precious. The mantra is simple: back up everything, replicate it, archive it, and build systems resilient enough to withstand any catastrophe. This doctrine is so ingrained that to question it feels almost heretical. Yet, I want to propose a dangerous, counterintuitive idea: what if the path to greater reliability lies not in saving everything forever, but in deliberately designing systems where some data is allowed to be ephemeral, to be lost, to die?
The common advice is a fortress mentality. We build moats and walls around our data, terrified of a single bit flipping in anger. We invest immense resources in backup strategies, multi-region replication, and long-term cold storage, often for data whose loss would be nothing more than a minor, temporary inconvenience. In our quest for perfect preservation, we have forgotten the art of letting go. We treat all data as if it were a priceless, irreplaceable family heirloom, when most of it is closer to the day's newspaper—valuable for a moment, but destined for the recycling bin.
This over-preservation has tangible costs, and I'm not just talking about the obvious ones like storage bills. The true cost is complexity. Every system for backup, replication, and archival is another layer of intricate machinery that can fail. A backup script with a silent bug becomes a time bomb. A replication lag creates a split-brain scenario more damaging than a simple outage. The very tools we use to build our fortress become its weakest points. The commitment to never lose data creates a system so complex that its failure modes become unpredictable and catastrophic.
Instead, consider the elegance of a system with a short memory. A message queue that acknowledges a message only after processing and then discards it. A caching layer that holds state for just long enough to be useful, then gracefully forgets. A log file that rolls over and purges old entries, accepting that last week's debug traces are no longer relevant. These systems are simpler, more predictable, and often far more robust. Their failure modes are known and manageable: a service restart means starting fresh, not reconciling gigabytes of ambiguous state.
This philosophy is about defining what truly matters. By consciously identifying which data is critical—the user's final, saved document; the committed transaction in the database—and which is transient—the intermediary calculation, the temporary session data—we can build a cleaner architecture. We protect the crown jewels with fierce, focused intensity, while allowing the supporting cast of data to come and go as needed. This selective preservation forces a clarity of design that sprawling, save-everything approaches often lack.
Embracing the unrecoverable is not an act of negligence; it is an act of discipline. It is the recognition that immortality for every byte comes at the price of systemic fragility. By allowing some data to be mortal, we build systems that are not only simpler and more reliable but also more honest about what is truly important. The goal is not to lose data carelessly, but to design systems where the loss of certain data is an accepted, non-catastrophic part of their normal, healthy operation. Sometimes, the strongest system is one that knows how to forget.
Notes & further reading
A few pages I came back to while writing this: