If you’ve read up on the GDPR basics (what personal data is, the 7 data handling principles, the rights users can exercise), you know the theory. Now let’s talk about what happens when you try to actually implement all of that in a microservices architecture. Because everything that’s simple in a monolith becomes a coordination problem the moment your data is spread across dozens of services.

The Core Problem

In a monolith, personal data lives in one database. When a user asks “what do you have on me?”, you run a query. When they say “delete everything”, you run a delete. Done.

In microservices, that same user’s data is scattered across your user service, order service, notification service, analytics pipeline, search index, message queue, and probably a few places you’ve forgotten about. Every GDPR right (access, erasure, portability, rectification) now requires coordination across service boundaries, team boundaries, and often technology boundaries.

Here’s what that looks like in practice.

Data Discovery

When a user submits a subject access request (“show me what you have on me”), you need a complete answer. Not a partial one, not a best-effort one. You need to know every service that holds personal data for that user.

You need a data catalog or registry that maps which services hold personal data and what kind. Without it, you’re guessing. And guessing isn’t compliance.

Erasure Propagation

A deletion request can’t just hit one service. It needs to cascade across every service that holds that user’s data. And when I say every service, I mean: think about all the places data actually lives. Primary databases, read replicas, caches, search indices, CDN edges, data warehouses, backups.

The practical approach is to treat deletion as a process, not a single event. Build an erasure pipeline that publishes deletion events to a distributed queue like Kafka, and have each service that holds personal data subscribe and handle its own cleanup.

But it doesn’t stop at publishing an event and hoping for the best. You also need tracking to verify that every service actually completed the deletion. What happens when one service is down during the erasure event? You need retries, dead letter queues, and a way to audit completion across the board.

Event Sourcing & Immutability

If you’re using event sourcing, you have a direct conflict: GDPR says users can demand their data be deleted, but your event store is designed to be immutable. Events are records of the past. You can’t just delete them without breaking your event log.

The most practical solution is crypto-shredding. Instead of deleting events, you encrypt all personal data in events with a key that’s unique per user. When a user exercises their right to be forgotten, you delete the encryption key. The events still exist, but the personal data in them becomes permanently unreadable.

What makes this work so well is that it covers your entire pipeline. The encrypted data in any service, log, or backup that processed those events becomes useless without the key. One key deletion, and the user’s personal data is gone everywhere, without touching the event store’s immutability.

Inter-Service Security

In a monolith, your security boundary is the application itself. In microservices, each service that handles personal data needs its own authentication and authorization layer. You can’t assume that because a request made it past the API gateway, it’s authorized to access personal data in downstream services.

This matters because the biggest threat to data privacy isn’t external hackers. It’s internal access. When any developer can deploy a service that talks to other services holding personal data, your attack surface grows with every new microservice. GDPR requires data protection by design, which means perimeter security alone isn’t enough. Each service needs to enforce its own access controls.

Consent isn’t a one-time checkbox. Users can grant consent for specific purposes and withdraw it at any time. In a microservices setup, every service that processes personal data needs to know the current consent state for that user and that purpose.

This usually means building a central consent service that other services query, or propagating consent state changes via events. Either way, you’re dealing with eventual consistency and the question of what happens when a service processes data in the window between a consent withdrawal and the event arriving.

There’s no perfect answer here, but you need to at least have a strategy. And “we didn’t know the user revoked consent” isn’t one.

Retention Policies Per Service

Different services have different legitimate reasons to keep data for different periods. Your billing service might need invoice data for seven years due to tax regulations, while your analytics service has no reason to retain personal data beyond 30 days.

Each service needs its own TTL-based cleanup strategy, and you need a way to audit and verify that these policies are actually being enforced across your entire system. A retention policy that exists in a Confluence page but not in your code is just wishful thinking.

Breach Notification: The 72-Hour Clock

If a personal data breach occurs, GDPR requires you to notify the supervisory authority within 72 hours of becoming aware of it, and affected users must be informed if the breach poses a high risk to them.

In a distributed system, even detecting that a breach happened is a challenge. A compromised service might expose data that flows through multiple other services. You need centralized monitoring, incident detection, and alerting that can trace the blast radius of a breach across service boundaries. This isn’t something you want to figure out after something goes wrong.

What’s Next

GDPR turns data ownership from an afterthought into a first-class architectural concern. You need to know where data lives, how it flows, who can access it, and how to remove it, across every boundary in your system.

The good news is that most of these challenges have known patterns: data catalogs, erasure pipelines, crypto-shredding, consent services, centralized audit logging. The bad news is that retrofitting them into an existing system is painful.

If you’re designing a new system, bake these capabilities in from the start. If you’re maintaining an existing one, start by mapping where personal data lives and flows. That’s the foundation everything else builds on.