What should a system forget?

Reviews interrogate what a system stores: the schemas, the retention, the backups. We have started asking the inverse question, and it embarrasses more architectures than any other in our kit: what does this system deliberately forget, and on whose schedule?

The default answer, nearly everywhere, is nothing and nobody's. Storage is cheap, deletion is scary, and every table, topic and log stream accumulates by default. The costs arrive on three ledgers at once. The operational one: queries that slow as tables grow, reindexing windows that stretch, the analytics job that scans three years to answer a question about last week. The correctness one, which is subtler: stale state that remains addressable remains believable, and systems act on records that stopped being true years ago because nothing marked them dead. And the liability one, where retained data is attack surface, breach magnitude and regulatory exposure, a ledger the security review reads even when the architecture review does not.

why is forgetting a design problem rather than a cleanup?

Because deletion cannot be retrofitted by cron job. What can be forgotten is determined by what was entangled at write time: the audit line whose foreign key points into the customer table, the event log where one tenant's stream interleaves with everyone's, the cache whose keys encode nothing about age. An estate that never designed for forgetting physically cannot comply with a deletion request without a project, and we have reviewed two of those projects this year alone; both cost more than the systems they cleaned.

The pattern worth stealing appears, interestingly, in small systems more often than large ones. A home assistant build we reviewed with pleasure consolidates its experience into a memory graph and then deliberately prunes what has stopped being true, on a schedule, as a first-class function of the design rather than a cleanup apologized into a maintenance window. The build borrows its framing from human memory, where forgetting is not a defect of the mechanism but the mechanism's point: consolidation is selection, and a memory that keeps everything ranks nothing. One person's hobby architecture, and it answers a question most enterprise estates cannot.

what would have to be true to forget safely?

Three properties, each cheap at design time. Age is addressable: every record carries enough temporal metadata that "older than X and unreferenced" is a query, not an investigation. Truth has an expiry class: at write time, data is classified by how it dies (superseded, expired, revoked, never), because the class determines the mechanism, and classifying at read time is the project we just watched two companies fund. And deletion is exercised: the forgetting path runs on schedule against production, in small doses, because a deletion mechanism that has never run is a hypothesis, and the first real execution of a hypothesis should not be triggered by a regulator's letter.

The tradeoff, priced both ways: designing for forgetting costs a review question and some write-path metadata, paid once. Not designing for it costs query performance continuously, correctness incidents occasionally, and a compliance project eventually, and the eventually has a habit of arriving with a deadline attached and a lawyer holding it.

What should your system forget? If the review cannot produce a list, the system's answer is "nothing, forever, entangled", and that is not a retention policy. It is the absence of one, compounding.