Account Deletion Data: Retention, Separation, and Recovery Design

Source and AI note: This article is based on Gemini’s Devpractice on YouTube. It was generated and edited with the gpt-5.6-sol model.

The first design question for a deleted member’s order is not whether to rename it archived_order. It is where retained data must live. Putting another table beside live orders in the same schema was generally not enough; guidance often required another schema or, in most of the companies discussed, a separate database system.

Move retained orders to separate storage

The retained store can keep a table with the same purpose and move records that the applicable retention policy requires out of the live database. Transfer may happen during account deletion or later in a batch. Which route fits depends on the service’s deletion flow.

The required degree of separation varies with the audit or policy being applied. A physically separate database costs more, although retained-member traffic may be low enough for a smaller system. Engineers who are not legal or security specialists should follow the current interpretation supplied by the responsible experts or the review body the company must satisfy.

Deletion does not end an order

The harder questions appear in the business flow. If an order is still being delivered, many services block account deletion until the active transaction finishes. A defect may be discovered after departure and still lead to a cancellation or exchange through customer support. A recall may require contacting someone who already left. A service may also choose to restore purchase or payment history after re-registration.

Each policy changes which data must remain connectable and for how long. Encrypted identifiers and different expiry periods are examples, but the exact rules differ. If all identifying links are removed, later restoration becomes impossible; if links remain, their permitted purpose and deletion timing need an approved basis.

Let current guidance settle the details

This is why account deletion cannot be designed from a single remembered retention period. Personal data, payment records, re-registration, recalls, and former dormant-account rules may be treated differently and may change. Establish the applicable guidance first, then implement the corresponding separation, encryption, operational path, and eventual deletion. The database design follows that decision rather than inventing it.