Node.js 24 Runbook for Explicit Retention Gates Before Deleting Campaign Images and Videos

Starting with the user-visible outcome, a temporary upload generates one original image, several responsive thumbnails, and a generated video. Each object obtains its own immutable ID, while a campaign record maintains the parent-child relationship.

The retention rule states that derivatives should be deleted seven days after campaign closure, ensuring the original image remains intact for potential appeals or exports. Avoid inferring object ownership based on filenames or storage prefixes, as they change during transcoding, and multiple campaigns might share a common slug.

The cleanup worker reads a durable manifest, validates the campaign state, and submits individual deletion operations. In case of a second execution, it recognizes the same IDs and records an absent result as success. The deletion contract comprises four fields: asset ID, kind (source, thumbnail, or video), delete-after timestamp, confirmation state, reason, and actor. These fields transform a destructive operation into something explainable for on-call engineers during off-hours.

The postmortem review highlighted the dangers of using a single prefix operation following a campaign's end. It bundled unrelated objects, leaving no per-asset evidence, and caused retries to fail due to the lack of per-asset confirmation. The safer approach is to utilize a queue message per confirmed ID, carrying a deduplication key made up of campaign ID and asset ID.

The worker acknowledges the deletion only after the durable audit store confirms the operation. If the queue redelivers the message, the handler performs the same operation and records the same terminal state.

The cleanup worker includes four checks before initiating a destructive call:

1. Is the campaign past its retention deadline?

2. Does the manifest still link this ID to the campaign and kind?

3. Has a legal hold, export, or support case extended retention?

4. Is there any unknown information? If any answer is uncertain, defer the cleanup.

While a small Go worker implementing an explicit boundary offers benefits, it is crucial to have a durable manifest and the ability to make deletion responses auditable. If these aren't available, first implement a storage lifecycle policy with a quarantine window, then incorporate the manifest before automating destructive calls. When campaign state, derivatives, or review holds affect the deadline, use the application worker over a provider-managed lifecycle rule.

Retention metrics should include eligible assets, deletion attempts, confirmed deletions, deferred items, and the age of the oldest eligible item. Breakdown these counters by image and video, as they differ in bandwidth and storage consumption. Sample the manifest against the storage inventory while avoiding the logging of raw customer media or signed URLs.

Balance quality and bandwidth by adjusting thumbnail sizes and video encoding according to the campaign's quality standards. Finally, include retention in acceptance tests to ensure successful completion only after expected IDs are either deleted or deliberately held.