A product's growth team wants account deletion to take 30 days of "cooling off", during which the account is recoverable and the user receives win-back emails. The architecture already implements this as a soft-delete flag. What happens when the first erasure request arrives citing a legal right, and what should have been designed differently?

What happens, in order

A user asks for their data to be deleted, citing their rights rather than clicking the in-product button. Under the GDPR the controller has one month to respond, extendable to three for complex cases, and the response has to be substantive. A 30-day cooling-off period that the user did not choose is not an extension of that clock.

Legal asks engineering a simple question: what does the deletion actually do? The answer is that it sets a flag. Then the second question arrives, and it is the expensive one: where else does the data exist? Search indexes, the analytics warehouse, the recommendation feature store, event streams with a 7-day retention, the support tool, the marketing platform, last month's backups, and the logs. A soft-delete flag in the primary database affects none of them.

The third question is the one that changes behaviour: are the win-back emails still going out? If the flag suppresses the account but the marketing platform keeps its own copy of the address, the company is emailing someone who has formally asked to be erased, which converts a data-model problem into a regulatory one with a paper trail.

Where it amplifies

Every downstream copy is a separate deletion project, and each one has an owner who did not know they were in the deletion path. The work is not hard individually; it is hard because nobody has the list. Meanwhile the clock is running and the request is one of a queue, so the manual heroics that clear the first request do not scale to the fiftieth.

What stops it

• Separate the product feature from the obligation. A cooling-off period is a legitimate product choice for a user who clicks "delete my account" in the app. It is not available as a response to a rights request, so the architecture needs two paths: reversible account closure, and irreversible erasure with a deadline.
• Make deletion a fan-out with receipts. A deletion request emits an event; every system holding personal data subscribes, acts, and acknowledges. The control that makes it real is a completion record per system, because that is the evidence a regulator asks for and the only way to know the list is complete.
• Keep a data inventory that is a build artefact, not a document. Generated from schema annotations and enforced in the pipeline, so a new table holding an email address either declares itself or fails the build.
• Design for the copies that cannot be deleted per record. Immutable logs and analytics with an append-only model need either pseudonymisation with a deletable key, or a stated retention short enough that erasure is achieved by expiry. Choose that before the request, because there is no good answer to invent under a deadline.

What would have to be true for this to be fine

That the product's only deletion path is user-initiated and revocable, that no personal data leaves the primary database, and that nobody ever exercises a legal right. The first two are design choices you could actually hold; the third is not.

When this is the wrong framing

Not every retention period is a dark pattern. A cooling-off window genuinely protects users from account takeover and from their own mistakes, and a bank or a source-control host that erased everything instantly would be doing its customers harm. The test is who the delay serves and whether the user chose it: a recoverable window the user is told about, with erasure available on request, is defensible. A delay whose purpose is to send win-back emails is the same mechanism pointed at a different beneficiary, and the architecture cannot tell the difference — which is precisely why the decision belongs in the design review rather than in the growth backlog.