ORIGINAL COMPANY-CONTEXT PRACTICE
Propagate a user deletion through derived stores
Original practice scenario: A hypothetical social application stores posts in an operational database, search index, caches and recommendation features. Design an inspectable deletion workflow.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Enumerate the representations covered by the request and make deletion progress observable. Removing a primary row does not prove that copies, derived features or cached responses are gone.
Work through it
- Authenticate the request, assign a durable deletion job identity and record affected resource identities without copying unnecessary personal content into logs.
- Send idempotent deletion or invalidation commands to each covered store, retain completion receipts and retry failures with bounded backoff.
- Prevent stale reingestion using deletion versions or tombstones, then reconcile outstanding stores and expose partial completion to the responsible operator.
Tradeoffs to discuss
- Fast acknowledgment improves responsiveness but must distinguish request acceptance from completed removal; synchronous completion increases latency and dependency coupling.
Common pitfalls
- Define how backups, legal retention and shared-content references are handled instead of silently promising universal immediate erasure.
- A retrying data pipeline must not recreate content from an older snapshot after deletion.