Deletion across data systems is a workflow, not a query

Deleting a row from one database does not delete a subject from a modern data system. Copies may exist in an operational store, an analytical warehouse, a search index, generated artifacts, and retry queues, each with different consistency and failure behavior.

There is rarely one transaction that spans them all. Treat deletion as a durable workflow with per-store checkpoints, idempotent operations, and an auditable outcome that does not retain the data being erased.

Give the request a durable identity

This section creates one workflow record for an erasure request. It tracks progress without using a queue message as the only source of truth.

A workflow record makes partial progress explicit:

export type DeletionTarget =
  | 'operational'
  | 'analytical'
  | 'search'
  | 'generated-artifacts';

export type TargetStatus = 'pending' | 'running' | 'complete' | 'failed';

export type DeletionRequest = {
  requestId: string;
  subjectReference: string;
  createdAt: string;
  status: 'pending' | 'running' | 'complete' | 'failed';
  targets: Record<DeletionTarget, TargetStatus>;
};

subjectReference should be a protected internal reference, not an email or display name. After completion, the system may replace it with a one-way receipt token if retaining the lookup key would undermine the erasure.

The workflow record must be created before jobs are dispatched. If enqueueing fails halfway, a reconciler can still find a pending request and continue it.

Delete one store at a time

This section makes each target operation safe to run repeatedly. A retry after a timeout may not know whether the previous call completed, so “already absent” must count as success.

Each handler accepts the protected subject reference and returns a bounded result such as target, completion state, and deleted count. It does not return deleted content. Revoking access first narrows the window in which new activity can recreate data during deletion. Ingestion and background generation should also consult deletion state before writing new records.

Each store gets its own local transaction or bulk operation. Attempting to simulate one cross-store transaction usually creates a more fragile coordinator without giving true atomicity.

Checkpoint only after verification

This section advances the workflow only after a target deletion is both executed and verified. A completed checkpoint prevents successful stores from being repeatedly scanned on every retry.

A worker acquires an expiring lease, skips complete targets, marks the next target running, executes its idempotent handler, verifies absence, records a bounded receipt, and only then marks that target complete. The lease must work across instances and expire after a crash.

Verification should query by the protected reference and return a count, not copy deleted records into logs. Receipts need target, completion time, handler version, and aggregate count; they do not need the removed content.

Stop data from returning

This section handles the less obvious failure: deleting every current copy while an old queue message or scheduled job recreates one moments later. Erasure must participate in write authorization.

Shared write boundaries should consult a deletion registry before accepting work for the subject. Delayed queue messages and scheduled jobs must treat a blocked write as terminal rather than retrying forever. New ingestion should be rejected or quarantined according to the system’s retention obligations.

Retain the minimum tombstone needed to reject delayed work, using the retention and privacy rules appropriate to the system. Queue consumers should acknowledge blocked messages rather than retrying them forever.

Tests should interrupt the workflow after every target, resume it, and verify that completed handlers are skipped. Another test should deliver a stale generation job after deletion and prove that no artifact is recreated.

Cross-system deletion is complete only when current copies are gone and old work cannot bring them back. A checkpointed workflow makes partial failure recoverable while leaving a bounded receipt that proves what the system did.