A Data-Retention Interview Exercise for a New Product Feature
Practice a data-retention interview with minimum fields, age and count limits, deletion propagation, current access and safe restoration.
TL;DR
- In this fictional recently-viewed-documents exercise, every retained field should serve a defined feature purpose.
- Set age and count limits and trace deletion through derived copies.
- Check current authorization independently of viewing history and test expiration, deletion, and recreation across the lifecycle.
Turn retention into a feature decision
Use this fictional interview scenario: a product team wants to add a “recently viewed documents” feature. An initial proposal stores every view event indefinitely, including account, document, device and full request details. The interviewer asks you to review the design.
Begin with the user task. Does the feature need the latest few documents, a complete audit trail or cross-device continuity? Those requirements imply different data. Do not accept an unlimited event history as necessary merely because it is easy to collect at the ingestion point.
This is a technical design exercise, not legal retention advice. In a real system, applicable obligations and authorised policies need specialist input. In the interview, identify that dependency while still proposing a concrete minimal design for the stated feature.
Create a purpose-to-field map
For the fictional feature, suppose users need their recent document list across devices. A candidate design might retain user identity, document identity and a last-viewed timestamp for a bounded set of recent entries. That is an assumption to discuss, not a universal schema.
| Proposed field | Feature purpose | Question before retaining |
|---|---|---|
| User identifier | Retrieve the correct list | Can access remain account-scoped? |
| Document identifier | Open the referenced item | What happens when access is revoked? |
| Last-viewed time | Order the list | How precise must the timestamp be? |
| Full request payload | No stated list requirement | Why retain it here? |
| Device fingerprint | No stated continuity requirement | Is this separate purpose justified? |
A field may be needed by another approved system without belonging in this feature's store. Keep those purposes distinct so that a vague “analytics might need it” does not silently expand the design.
Define age and count boundaries
Discuss both elapsed time and maximum list length. A count limit alone can leave an inactive user's entries indefinitely. A time limit alone can permit an unexpectedly large volume for a heavy user. The appropriate values depend on the product task; do not invent a compliance period.
Specify whether opening the same document updates one record or creates another event. For a recent-items list, updating the last-viewed record may satisfy the feature without retaining a full behavioural history. If the product genuinely needs history, make that a separate explicit decision.
Clarify the user controls. Clearing the list should have an understandable effect. If a fresh view adds the item again, that is different from a permanent exclusion preference. The interface and backend should express the same promise.
Follow deletion through derived copies
Draw the data path: primary store, cache, search projection, analytics export and backup. Only include systems that actually receive the data, but do not stop at the table where it first arrives.
When an entry expires or a user clears the list, explain how active serving copies stop returning it. An asynchronous deletion job may require a tombstone or version boundary so that an old event cannot recreate the entry after deletion. The exact mechanism depends on the architecture; the important point is to account for replay and delayed processing.
Backups need a defined restoration procedure consistent with the approved retention policy. Do not promise immediate physical removal from every historical backup if the design cannot support that. Explain what happens when restoring a backup so previously deleted data is not quietly made active again.
Keep authorization independent of history
A recent-items entry is not permission to read a document. Check current access when serving the list and again when opening the target as appropriate to the architecture. The product may need to remove or hide metadata for documents the user can no longer access.
Imagine a user views a document, loses project membership and later opens recent items on another device. A cached title or preview could expose information even if the final document request is denied. Discuss the metadata path rather than claiming that protecting the document endpoint solves everything.
Our system design preparation guide can help you connect these access and lifecycle requirements before choosing a storage system.
Test the lifecycle, not just creation
Use a practice timeline: view a document, update the timestamp, clear the list, receive a delayed old event, revoke access and restore a test backup. For each step, state what the user should see and what stored state should remain under the chosen policy.
Measure failures that matter to the feature, such as expired entries still being served or deleted records being recreated. Avoid collecting an unnecessarily detailed audit stream merely to monitor a design whose purpose is to minimise retained history.
End the rehearsal with the smallest field set, the lifecycle rules and the unresolved policy questions. Use the mock interview strategy to explain the proposal without hiding uncertainty. The useful result is a feature whose data exists for a defined reason and whose deletion behaviour can actually be tested.