alt Hacker News> Event sourcing and "the right to be forgotten" are not always easy to marry.
The absolute basics is to support snapshots and event replay. This is hardly rocket science.
> Event sourcing and "the right to be forgotten" are not always easy to marry.
The absolute basics is to support snapshots and event replay. This is hardly rocket science.
If you try to redact a part of the past, it can also affect the present, as any time traveler knows.
Let's assume we want to remove every message related to user A.
A photo by user B got to be the best of the day because it collected most upvotes. Without the A's vote, it's no longer so. The photo also got to become the best of the month because it was later voted as the top from the best-of-the-day entries, and received a prize. Should we now play the message stream without the A's upvote, things are going to end up radically different, or end up in a processing error.
User B was able to send a message to user C, and thus start a long thread, because user A had introduced them. With user A removed, the message replay chokes at the attempt of B to communicate with C.
One way is to ignore the inconsistencies; it deprives you of most of the benefits of event sourcing.
Another way is anonymizing: replace messages about user A with messages about some null user, representing the removed users. This can lead to more paradoxes and message replay inconsistencies.