A legal hold lands on Friday afternoon and your nightly deletion jobs run at two. What do you do, and what do you build afterwards?

The first hour is about stopping the right things

A legal hold is an instruction to preserve material relevant to an actual or anticipated dispute or investigation. It arrives as words, not as a query, and the immediate engineering question is which of your automated processes will destroy something in scope before Monday. That is a smaller list than "all deletion" and a larger list than most teams expect, because deletion is not one job.

Halting everything is the reflex and it is a poor answer. It stops erasure requests you are obliged to fulfil, it stops the expiry of data you are not permitted to keep, and because a global pause is disruptive it creates pressure to resume before the scope is understood — which is how records get destroyed after the hold date. The stronger move is a narrow, aggressive suppression: identify the smallest set of subjects, accounts, matters or date ranges that certainly contains the scope, suppress deletion for that set across every path, and let everything else keep running. If the scope cannot be narrowed by two in the morning, widen the suppression for one night and narrow it in daylight, but record that you did so and why.

Hold has to outrank the retention schedule in code

If the only thing stopping deletion is a person remembering, the control does not exist. Hold belongs in the data model as a state that every deletion path consults, and the check must be a precondition of deletion rather than a filter applied by each job's own query — one job written by someone who did not know about holds is enough to lose the material.

-- The predicate is trivial: no unreleased hold may cover the subject. Where it
-- lives is the entire control. Written inline in a job's own DELETE it is only
-- advisory, and the next job, by someone who has never heard of holds, omits it.
-- Push it underneath every job instead, so opting out is not expressible.
ALTER TABLE interactions ENABLE ROW LEVEL SECURITY;
ALTER TABLE interactions FORCE ROW LEVEL SECURITY;  -- the owner is bound too

CREATE POLICY no_delete_under_hold ON interactions
  AS RESTRICTIVE FOR DELETE
  USING (
    NOT EXISTS (
      SELECT 1 FROM legal_hold_scope h
      WHERE h.subject_id = interactions.subject_id
        AND h.released_at IS NULL
    )
  );

A BEFORE DELETE trigger that raises does the same work with a clearer error, and so does revoking DELETE from every job role and granting only EXECUTE on a procedure that applies the check itself. Which of the three you choose matters far less than there being exactly one of them, and that a newly written job cannot reach the rows without passing through it. The same reasoning has to be repeated outside the database, because a policy in Postgres has no reach over an object-store lifecycle rule or a backup expiry schedule, and each of those needs its own single point where the hold is consulted.

The lifecycle has one transition that catches teams out, and it is not the one at the start.

flowchart LR
  A[Record created] --> B[Active retention]
  B --> C{Hold covers it}
  C -->|no| D[Deleted on schedule]
  C -->|yes| E[Preserved and deletion suppressed]
  E --> F[Hold released]
  F --> G[Deletion debt reassessed]
  G --> D

Look at the edge from released back to deletion. Records whose retention expired during the hold did not become permissible to keep; they were kept because a stronger obligation applied. When the hold lifts, that backlog has to be evaluated and processed, and if nothing owns that step the hold quietly becomes indefinite retention. Auditors and privacy regulators both find this, from opposite directions.

Enumerate every path that destroys data

The operational database is the path everyone remembers. The ones that quietly run anyway:

• Backup and snapshot expiry. A snapshot due to age out this weekend may be the only copy of a version of a document that has since been edited. Extending its life is usually the right call, and it has a cost and a residency consequence you should state.
• Log and telemetry rotation. If the dispute concerns who did what, access logs and application traces are frequently the most relevant material, and they typically have the shortest retention in the estate.
• Stream compaction and topic retention. A compacted topic drops superseded values, which for an audit question about what changed when destroys precisely the interesting part.
• Object lifecycle rules. Storage-side rules run outside your application entirely and answer to no feature flag you control.
• Third parties. Mailbox retention policies, ticketing systems, chat history, the analytics vendor. Each has its own clock and its own hold mechanism, and none of them read yours.

Enumerating this list is the same capability an erasure request needs — knowing everywhere a subject's data lands. Teams that have built one can do the other in an afternoon; teams that have built neither discover both problems at once, under a deadline set by someone else.

Preservation itself becomes evidence

The hold generates records that matter as much as the preserved data. Who issued it, when it was received, what scope was interpreted from it, which systems were suppressed and at what time, what could not be suppressed and why, who approved widening or narrowing, and when it was released. Keep that in the audit trail with the same tamper-evidence you apply to any other privileged action, because the question you may have to answer later is not only "do you still have the records" but "can you show that nothing in scope was destroyed after you were notified".

The related trap is the audit trail of the hold's own enforcement. If suppression is implemented by an engineer running a script with elevated rights, the intervention is unreviewable and the person who could destroy the evidence is the person attesting that they did not. Suppression should be an authorised change with an approver, deployed through the normal path, precisely because the circumstances make its integrity contestable.

When a hold and an erasure request point at the same person

This is the collision worth being crisp about, and crisp does not mean confident about the law. Engineering-wise: you do not delete while the hold stands, you record the erasure request with its received date so the clock is visible, you fulfil the parts of it that fall outside the hold scope if your compliance function agrees they are separable, and you resume the rest when the hold releases. Every one of those is a decision your legal or privacy function makes and yours to implement — the erasure right yields where a stronger legal obligation to retain applies, but whether this particular hold constitutes that, and what the subject is told meanwhile, is not an architect's call. Saying so plainly is a stronger answer than picking a side, and pretending otherwise is how engineers end up personally named in a process nobody wanted them in.

What you should insist on is that the system can represent the state: a subject who is both under hold and pending erasure, with dates on each, so the resolution is a query rather than an archaeology exercise.