Design how a backend handles account deletion, retention periods, and cleanup of related data.

Design data retention and deletion workflows

Designs deletion, retention, soft delete, hard delete, backups, audit records, and asynchronous cleanup across related data.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would start by classifying data: account profile, tenant data, files, billing records, audit records, derived data, and backups. Some data can be soft-deleted first, some needs retention for legal or business reasons, and some can be anonymized or hard-deleted. The API would create a deletion request, show status, and run cleanup asynchronously so large cascades do not block the request.

Full answer below

Practice focus

Retention policy, soft delete, hard delete, cascading cleanup, backups, audit records, privacy, and operational safety.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Deletion design is harder than calling delete on one row. Real systems have related data, files, audit records, backups, legal holds, and product expectations.
I would start by classifying data: account profile, tenant data, files, billing records, audit records, derived data, and backups. Some data can be soft-deleted first, some needs retention for legal or business reasons, and some can be anonymized or hard-deleted. The API would create a deletion request, show status, and run cleanup asynchronously so large cascades do not block the request.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would design deletion as a workflow with states like requested, scheduled, processing, completed, failed, and cancelled if policy allows cancellation. Background workers would delete or anonymize related records in safe batches and record progress. Files, search indexes, caches, read models, and queued jobs need cleanup too. The design would define what remains in audit logs and how those records avoid storing unnecessary personal data.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Deleting only the account row and leaving related data behind.
Ignoring files, caches, search indexes, and read models.
Treating audit logs and backups as if they disappear instantly.
Running a huge cascade delete in a request.

Design how a backend handles account deletion, retention periods, and cleanup of related data.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement