jm + event-sourcing   2

Twitter thread regarding GDPR-compliance for append-only logs/event sourcing systems
Martin Kleppmann: "What’s current best practice for GDPR compliance (in particular, right to deletion) in systems with append-only logs/event sourcing/blockchains, which are supposed to keep history forever?"

Ben Kehoe: "Crypto delete. The immutable store keeps an encrypted copy, and the key is stored elsewhere. Forget me = throw away the key".

That seems to be the most practical suggestion in general in this thread.
twitter  threads  gdpr  compliance  law  eu  append-only  logs  blockchain  event-sourcing  architecture  storage  kafka  kinesis 
june 2018 by jm
John Carmack's .plan update from 10/14/98
John Carmack presciently defines the benefits of an event sourcing architecture in 1998, as a key part of Quake 3's design:

"The key point: Journaling of time along with other inputs turns a
realtime application into a batch process, with all the attendant
benefits for quality control and debugging. These problems, and
many more, just go away. With a full input trace, you can accurately
restart the session and play back to any point (conditional
breakpoint on a frame number), or let a session play back at an
arbitrarily degraded speed, but cover exactly the same code paths."

(This was the first time I'd heard of the concept, at least.)
john-carmack  design  software  coding  event-sourcing  events  quake-3 
november 2012 by jm

Copy this bookmark: