Skip to content

GDPR and Data Privacy

Event Sourcing brings powerful benefits – but it also raises important questions around data privacy and regulatory compliance, especially under laws like the GDPR (General Data Protection Regulation).

The key challenge: Events are immutable – but personal data must sometimes be deleted.

Why This Is a Problem

Under Event Sourcing, data is stored as an append-only log of past events. That's great for auditing and debugging – but what if a user invokes their right to be forgotten?

You can't just "update" or "delete" an old event.

Common Strategies

There are two main approaches to dealing with personal data in an event-sourced system:

Externalize Personal Data

Instead of storing personal data directly in the event:

  • Store a reference to a separate, mutable data store
  • Use that store to retrieve personal data when needed
  • Delete or anonymize it separately when required

This keeps the event history clean – but comes at the cost of extra lookups and more moving parts.

Key Shredding (Crypto-Deletion)

If personal data must be part of the event:

  • Encrypt it using a unique key per user or stream
  • To "delete" the data, destroy the key
  • The data remains physically present, but becomes unreadable

This preserves event immutability while ensuring data is no longer accessible.

Other Considerations

  • Avoid storing sensitive data in events unless absolutely necessary
  • Use event metadata (e.g. timestamps, correlation IDs) wisely, but carefully
  • Provide tools for exporting and auditing personal data when required

Summary

Event Sourcing and privacy can coexist – but you need to be deliberate in your design.

  • Think ahead about data classification and retention
  • Choose the right pattern for each use case
  • Document how personal data flows through your system

Next up: See how to manage change in an event-sourced system with Event Versioning.