IME, ideal state is that 'soft deletes' are kept primarily for easing debugging, and the 'soft delete' is kept until archival of soft deleted events occurs (also primarily for debugging/compliance, but sometimes having 'recent data' closer to runtime makes debugging cycles easier...

The biggest problem in doing so successfully is getting the design of things right, which is hard to get buy-in on.

IMO, this is b/c it takes years to learn and apply, on top of already having significant CRUD experience

Corporate drones are not incentivized to do this, and startup people are pressed with time

So it may only work if there are highly motivated people, who may peridically ask for help from expirienced consultants, but not fully rely on them.

So do it this way:

> It’s better to model a lifecycle of such an entity as an FSM