Modern privacy regulations require organizations to delete customer data across all systems, within defined timelines.
As organizations accumulate more systems, data stores, and third-party integrations, the operational complexity of deletion often grows faster than their ability to execute it consistently.
The challenge is that deletion is often treated as a compliance workflow when it is fundamentally a distributed systems problem.
Most production systems were designed to collect, replicate, retain, and analyze data — not remove it. Yet a single deletion request may require coordinated actions across databases, object stores, search indexes, event streams, backups, internal services, and third-party systems.
As a result, deletion is rarely a single action. It becomes a coordinated execution problem spanning systems that were never designed to support it.
The hidden complexity behind a “simple” deletion request
From a user’s perspective, deleting personal data sounds simple.
Inside a modern organization, the same request can require teams to:
- Locate all systems containing relevant customer data
- Resolve identifiers across different schemas and services
- Execute system-specific deletion logic
- Verify that each operation completed successfully
- Retry failures without introducing inconsistencies
- Produce evidence for auditors and compliance teams
- Prevent downstream pipelines from recreating deleted data
A single customer identity may exist as a primary key in a transactional database, a foreign key in a billing system, an attribute in an analytics platform, and buried inside massive, unindexed object-store files that mix data from many customers. Deleting that customer requires understanding how each data store models data, and ensuring each system handles removal correctly.
The core difficulty is coordinating deletion across systems with different ownership models, deletion semantics, retention policies, operational constraints, and failure modes - all of which evolve independently over time.
The execution gap in privacy tooling
The privacy technology ecosystem has matured significantly. Organizations now have access to tools for privacy request management, governance, and data discovery.
These tools address important parts of the problem.
But they do not solve the execution challenge: How do you reliably orchestrate deletion across heterogeneous systems within your infrastructure?
Governance platforms help define what should happen. Cloud-native capabilities help execute deletion within individual systems. Between those layers lies the work of coordinating deletion across real production systems.
Organizations often fill this gap with scripts, service-specific workflows, and operational procedures that become increasingly difficult to maintain, validate, and audit as architectures evolve.
Why we’re focusing on right‑to‑erasure
Among privacy requirements, right-to-erasure places some of the greatest demands on an organization’s architecture.
Unlike many privacy obligations, deletion cannot be satisfied through policy alone. Organizations must coordinate actions across all systems where customer data resides and demonstrate that those actions completed as intended.
This exposes architectural inconsistencies that might otherwise be missed:
- Systems that interpret deletion differently
- Incomplete or unverifiable audit trails
- Service-specific workflows that are difficult to maintain
- Fragile operational dependencies
- Manual processes that don’t scale
Right-to-erasure is therefore more than a privacy requirement. It is a stress test of an organization’s ability to manage data consistently across its infrastructure.
Our perspective: privacy should be an architectural capability
The industry has largely approached privacy as a governance problem.
However, governance alone does not execute deletion, validate outcomes, recover from failures, or provide consistent guarantees across distributed systems.
We believe privacy obligations increasingly depend on infrastructure capabilities that most organizations were not designed to provide.
That means treating privacy as a first-class architectural concern rather than a collection of scripts and workflows. Organizations need a way to define deletion behavior consistently, execute it reliably across systems, and verify outcomes with confidence.
This perspective drives our exploration of privacy infrastructure and the patterns required to support it.
What comes next
Over the coming months, we’ll be sharing observations, architectural patterns, and practical analysis from our work in this space. Our focus is on understanding the real operational challenges behind privacy-driven deletion and how they can be addressed reliably and at scale.
If you’re an engineer, architect, or privacy specialist wrestling with these problems, we hope you’ll find the discussion useful. The infrastructure challenges behind privacy remain significantly under-addressed, and there’s a lot of ground to cover.