Identity-Record Separation

Regulation frequently requires you to keep a record and to delete a person's data, and the same row can be subject to both. A financial transaction may carry a multi-year retention obligation while the personal data attached to it is subject to an erasure right.

Designing them as one policy guarantees violating one of them. The resolution is structural: keep the business facts under a pseudonymous subject reference, and hold the mapping from reference to person in a separate store governed by the erasure rules. Deleting the mapping renders the retained records non-identifying while preserving them for their regulatory purpose.

Why it matters

This must be designed early. Retrofitting it means rewriting every table that embedded an email address, a phone number or a name — which in most systems is nearly every table, plus every derived copy in analytics, search and backups.

Implementation patterns

• A subject reference as the only identity carried in business records, with no personal attributes denormalised alongside for convenience. That denormalisation is exactly what makes the pattern fail.
• The mapping store as the single place personal data lives, with its own access controls and its own lifecycle.
• Deletion propagated as an event to every derived store, with completion tracked rather than assumed. Deletion that does not reach backups, replicas, caches, analytics copies, search indexes and third-party processors is not deletion.
• Legal hold overriding deletion, recorded with scope, reason and author. Deletion therefore cannot be a cron job doing hard deletes; it must go through a service that checks holds and produces evidence.
• Retention enforced by platform features — table-level policies, object lifecycle rules — rather than by application code someone must remember to write.
• An agreed backup policy, because an immutable backup taken before a request still contains the data, and the usual resolution is a documented retention window agreed with legal rather than assumed by engineering.

Industry example

Consumer fintech platforms such as CRED, Jupiter and Slice accumulate transaction records under financial retention obligations alongside behavioural and derived data under privacy obligations. The tension is real and unavoidable, and the separation is the only design that satisfies both without a per-request legal judgement.

The same structure applies to insurance claims, payroll records, healthcare interactions and any regulated consumer product — and the lifecycle stages are the same: hot operational, warm analytical, cold archival, deleted.

Failure scenarios

• Personal attributes denormalised into business records "for reporting", defeating the separation.
• Deletion that misses derived copies, so the obligation is silently unmet in the places nobody inventoried.
• No data inventory, which makes governance impossible — you cannot apply a policy to data whose existence is unknown, and derived copies are where the unknowns live.
• Hard deletes with no hold check, destroying evidence subject to a legal hold.
• Deletion completion assumed rather than tracked, so a failed propagation is invisible.

Trade-offs

The separation costs a join for every operation that needs both the record and the person, which is many of them, and it makes ad-hoc analysis harder because analysts cannot see identities without going through a governed path. That friction is partly the point and partly a genuine productivity cost.

It also creates a single high-value store holding all personal data, which concentrates risk. That store needs disproportionate protection — encryption, tight access control, comprehensive audit — and the concentration is usually judged an acceptable trade because protecting one store well is more achievable than protecting personal data scattered across forty.

Interview question

"A customer exercises their erasure right. Their transactions are under a seven-year retention obligation. Walk me through exactly what gets deleted, what is retained, and how you prove afterwards that you did both correctly."