Write a Safe Data Deletion Flow
Added 2026-11-03
Soft delete, confirm, then hard delete — with an audit trail.
We need to delete a batch of user data (context below). Design the deletion flow: 1) stages — mark, soft delete, hard delete — with timing and conditions; 2) related data to check first: backups, logs, analytics, downstream sync; 3) who can request, who approves, how to prevent mistakes; 4) what users are told and the undo window; 5) verification and records afterwards; 6) the three places data most often survives deletion.
Site original
Chinese original
How to use
删除流程的重点是「可反悔」，不是「删得快」。
Try tweaking it
- Have it restate requirements and constraints before writing code.
- Ask for the smallest change plus a rollback path, not a full-file rewrite.
What you should get
- A minimal, runnable change with copy-ready code
- Impact list: which files and call sites must follow
Common mistakes
- Asking it to touch ten files at once, then losing track of what broke what.
- Pasting only the error, with no code or version, and getting an unfixable answer.
How to check the output
- The change runs, can be rolled back, and touches nothing unrelated.
- Edge cases (empty, oversized, concurrent) are covered or explained.
Where it works
- Good for: having it restate requirements and constraints, then propose the smallest runnable change.
- Watch out: include versions and a minimal reproduction with the error, or the fix may look plausible but not fit.
Good for
- A user or legal team has requested deletion of production data, and you need it gone without deleting the wrong thing.
- You are about to clean up historical data and worry copies remain in analytics, backups or caches.
Not for
- You are only hiding one record that the user may restore — use a soft delete or status flag, not the full flow.
- The dataset is tiny, has no downstream consumers and no compliance requirement — delete it directly and log it.
Example
Input
Delete all data for three users: primary users/orders/messages tables, a read replica, a warehouse that syncs daily, object storage for attachments, a CDN, and seven-day backups.
What you get
Stage it: mark today, soft delete and remove from read paths today, hard delete after seven days to outlive backups, then verify. Before deletion, check replica lag, the warehouse sync window, the attachment inventory in object storage, CDN cache keys and the backup retention policy. Requester is support, approver is the data owner, and execution needs a second confirmation plus an audit log. The undo window sits between soft and hard delete. Verify five places: primary rows at zero, replica caught up, warehouse rerun shows nothing, attachments return 404, cache purged. The usual survivors are backups, the warehouse and PII inside logs.
Common mistakes
- Running DELETE directly: no approval, no verification, no proof of completion and no recovery if it goes wrong.
- Deleting only the primary database: replicas, warehouse, object storage, CDN and logs still hold the data.
Try tweaking it like this
- Design from the user-visible side: remove the data from their view first, finish hard deletion in the background.
- Design for minimum irreversibility: soft delete with a snapshot, confirm no business impact, then hard delete.