← Back to context

Comment by motorest

12 hours ago

Event sourcing also works great. You don't need an audit log per se if you already track a history of all commands that introduced changes to your system.

Event sourcing and "the right to be forgotten" are not always easy to marry.

  • > 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.

      1 reply →

Yep. But Event Sourcing comes with its own set of other problems. Also, I don't think this would apply to OP's post: with Event Sourcing you would not even have those DB tables.

  • The DB tables suggested by OP are a kin to snapshots, whereas each event would require a separate data store. OP is trying to shoehorn event history into the snapshots, which hardly makes any sense.