Legal Hold
Suspending deletion for specific records because of anticipated litigation or investigation, which must override the retention schedule and be provable.
Retention policy deletes on schedule. Legal hold stops it for defined records, and the two obligations point in opposite directions — which is why a system with only one of them will eventually breach the other.
Three properties are needed. It must override automated deletion, including the routine purge job, the retention policy on the object store and the log rotation. It must be selective, applied to records matching a scope such as a custodian, a matter, or a date range, rather than by suspending deletion globally — which is the crude workaround and creates its own privacy exposure. And it must be auditable: who applied it, when, over what scope, and when it was released, because failure to preserve carries serious consequences and the defence is the record of what was done.
The engineering difficulty is that the scope of a hold rarely matches the architecture's partitioning. "All communications involving these four people between these dates" spans email, chat, ticketing, call recordings and documents, each with its own retention mechanism and its own definition of a custodian.
The design response is to make the hold flag a first-class attribute honoured by every deletion path, rather than a separate process attempting to intercept them.