Project: verified data expiry

Last updated: 5 Oct 20268 min read

project

Build an expiry workflow for case 47 under a retention policy supplied by the product owner. Inventory its primary row, search document, attachment variants, export artifacts, browser caches, logs, queued events, and backups. When the deadline arrives, a stable operation ID gates new reads and starts idempotent cleanup tasks. A missing primary row is not the complete result. Search deletion fails once and leaves a visible partial-failure state with a retry owner. A later index rebuild and an old queued add event must honor the deletion marker. Restore a backup taken before the deletion into an isolated environment; replay tombstones and verify the case stays unavailable before traffic opens. Finally switch from reviewer 29 to reviewer 62 in one browser and clear application-controlled private state while server revocation remains effective even if client cleanup fails.

Build contract

Document each store, purpose, access scope, approved retention period, deletion mechanism, and verification signal.
Model export and erasure as private jobs with accepted, running, partial-failure, and complete states; authorize their status separately.
Keep deletion markers long enough to cover restorable backups and rebuild derived indexes from reconciled state.
Test account switching across memory, IndexedDB, service-worker caches, restored pages, and unsent offline drafts.

Implementation checkpoint

function deletionComplete(storeStates) {
  return storeStates.length > 0 && storeStates.every(state => state === "verified");
}
console.log(deletionComplete(["verified", "retry", "verified"]));
// Output: false

Cost and boundaries

Cleaning k active stores takes at least O(k) verified steps per case, and replaying d deletion markers after a backup restore adds O(d) work before derived indexes rebuild. A pending queue and temporary export artifacts consume bounded storage while jobs run. Scanning n browser cache keys may take O(n) on account switch unless the storage scheme provides scoped deletion. Extra evidence records use space, but they should contain operation and store outcomes rather than the private case body. Measure oldest overdue cleanup, artifact lifetime, restore time, tombstone replay, and residual private browser data after a switch.

Failure drill

Expire the primary row and deliberately leave its search document and old export artifact accessible; completion must remain false. Fail one cleanup worker after its queue message is accepted and verify the UI does not say Deleted. Rebuild the index from stale events and restore a pre-deletion snapshot; case 47 must not return. Remove deletion markers earlier than backup expiry in a test environment and show why a later restore would resurrect it. During account switch, force IndexedDB cleanup to throw. The old server session must still be revoked and private requests denied. Document that a downloaded file cannot be remotely erased.

Acceptance checks

Completion requires verified active-store outcomes, not one database response.
A failed derived-store deletion remains visible and retryable while reads are gated.
Restored backups and replayed events cannot revive a deleted case.
Old account browser data is cleared where controlled and server denial survives cleanup failure.

Common Mistakes

Treating a queued deletion job as a terminal result.
Ignoring search, exports, and browser storage after primary deletion.
Expiring tombstones before backups that contain the record.
Promising immediate physical erasure of every backup byte without a matching policy.

web-tech

web-development