Hacker News Reader

Comment by dfee | Hacker News Reader

My experience is that soft-deletes are blunt tools bridging the gap between hard deletes and event sourcing (capturing all the changes against the table, in a replay-worthy stream).

Event sourcing is hard – because the engineers responsible for setting it up and managing it aren't generally well skilled in this domain (myself included) and there aren't a wealth of great tools helping engineers find their way into the pit of success.

The downsides of soft-deletes (as identified in the article) are numerous. The biggest problem is that it appears "simple" at first blush (just add a deleted_at column!), but it rots your data model from the inside out.

View on HN

Or you can see it the other way around: soft-deletes are a pragmatic alternative to event sourcing that provides a lot of the value without requiring a team of super-humans and a radical redesign of the existing systems.

Just want to add that the downsides as identified in the article make little sense. Deleting a customers invoices should be a very rare thing. I can't imagine any accountant or auditor is going to be happy with an IT guy deciding when to delete invoices.

If accidentally writing the wrong query is a problem, then writing the wrong query is your problem.

The question for either of these systems IMO is: do you trust that a change from your upstream represents a true, everlasting intention, or is it something that may need to be reinterpreted or rolled back in the future?

At my startup, soft deletes for our SKUs are critical, because we work with data sources where notoriously both the technical systems and the humans driving will all-too-frequently accidentally represent something to our connection as deleted. Or there might be an irrecoverable error when asking "what things are still active upstream" - but that doesn't mean the SKUs are deleted, we might just not have certain live details until a bugfix is made. So "error status" and "soft delete" are somewhat synonymous, and both require investigation into root causes and root intents. Yes, the concept of "unerrored and active" is peppered through our codebase and analytics - but our ability to recover from supplier technical mistakes is much higher as a result. And we could absolutely do this with an event sourced system - but the tooling for relational databases is so much better, it's night and day.

An event store is just a special case of a temporal database. The whole point of temporal databases is to natively support the notion of historical vs. current data.

> My experience is that soft-deletes are blunt tools bridging the gap between hard deletes and event sourcing

Agreed, sometimes it makes business-sense to implement it, but in the big picture it's still kludgy and not-ideal.

While full-on event-sourcing isn't always the answer, once business-rules prevent you from un-deleting anything there's not much point of having all those dead-rows interspersed in your regular tables.

You can restore to any point of time from your database backup. So it can cover some requirements.

Reply on news.ycombinator.com