6 ms·

What makes event sourcing poor for general purpose stuff?

Spartan-S63 5y ago
Not OP, but the number of variants in the events makes the cardinality of the state of the system extremely large. Probably too large to be able to reason about fully. It makes weird bugs in the event schema likely impossible to debug should they occur.
- 88913527 5y ago
  This is exactly why 2-way data binding fell out of favor in modern UI development. Describing the problem as "the cardinality of the state of the system extremely large" is a succinct way of putting it. The non-linear increase in possible state quickly makes testing an uphill battle. And it's over when you can't have a comprehensive testing strategy, forget about it.
  - Spivak 5y ago
    Eh, two-way binding is still alive and well it’s just implemented explicitly on top of one-way bindings. It seems most developers find this easier to reason about but the relationship is still there. Like if all you’re doing is using the event to take the value from the UI and shove it into the model with setState and re-render then you made a two-way binding. Wouldn’t it be helpful if you could tell React to just do this for you and save you the boilerplate? Boom you invented ng-model.
  - square_usual 5y ago
    2-way bindings are still alive and well in the big "next gen" web frameworks, Vue and Svelte.
- btown 5y ago
  Can this be mitigated by ensuring that historical/legacy events are all transformed to more modern equivalents? Similar in theory to https://stripe.com/blog/api-versioning https://stripe.com/blog/api-versioning ? Then you at least have a chain of testable transformations and a reduced cardinality for the actual interactions that reflects the cardinality of all the ways your business users actually use your product today. Of course, this can be lossy, but is it any more lossy than the non-event-sourced CRUD system which is essentially transforming historical events into "overwrite these fields" events that can only be used for their original purpose? To me, the reason not to use event sourcing is more that the tooling and developer experience is just really poor - and so decisions like the above, while valuable to think through directly, rapidly become overwhelming. Visualizations of system state are only as good as the code you bring yourself. I'm hopeful that people building tools on top of things like https://materialize.com https://materialize.com will start to change this though!
_3u10 5y ago
Event sourced systems are actually great, as long as they aren’t branded as such. Most of the time it’s totally stupid and the state of the system isn’t reproducible anyway unless the event code is never modified.
mr_tristan 5y ago
This seemed like a great rundown on why event sourcing is complicated: https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-...
bsder 5y ago
Event sourcing is decent when you ingest a lot of things that are mostly one way and immutable once they come into your system. If you have bidirectional communication, you wind up contorting yourself into a pretzel to bury "state" into your event streams.
wrwatson 5y ago
The first rule of data modelling is that you should model only what you care about. A good model allows you to store and retrieve what you need to meet your requirements. Maybe you care about all the events that have ever happened on your incredible journey to reach a list of the customers you have today. Or maybe it would be sufficient to have been mutating a customers table all along. If that is sufficient, then it would be faster and more straightforward to have done so.
- mistahenry 5y ago
  This is why I always like to have a `status_history` or `audit` table. You don't have to have event sourcing to still want a trail of who changed what in the system when.
holoduke 5y ago
Extra layer of complexity. More development time. More tech dependencies. Don't use it when not needed.

Not OP, but the number of variants in the events makes the cardinality of the state of the system extremely large. Probably too large to be able to reason about fully. It makes weird bugs in the event schema likely impossible to debug should they occur.

88913527 5y ago
This is exactly why 2-way data binding fell out of favor in modern UI development. Describing the problem as "the cardinality of the state of the system extremely large" is a succinct way of putting it. The non-linear increase in possible state quickly makes testing an uphill battle. And it's over when you can't have a comprehensive testing strategy, forget about it.
- Spivak 5y ago
  Eh, two-way binding is still alive and well it’s just implemented explicitly on top of one-way bindings. It seems most developers find this easier to reason about but the relationship is still there. Like if all you’re doing is using the event to take the value from the UI and shove it into the model with setState and re-render then you made a two-way binding. Wouldn’t it be helpful if you could tell React to just do this for you and save you the boilerplate? Boom you invented ng-model.
- square_usual 5y ago
  2-way bindings are still alive and well in the big "next gen" web frameworks, Vue and Svelte.
btown 5y ago
Can this be mitigated by ensuring that historical/legacy events are all transformed to more modern equivalents? Similar in theory to https://stripe.com/blog/api-versioning https://stripe.com/blog/api-versioning ? Then you at least have a chain of testable transformations and a reduced cardinality for the actual interactions that reflects the cardinality of all the ways your business users actually use your product today. Of course, this can be lossy, but is it any more lossy than the non-event-sourced CRUD system which is essentially transforming historical events into "overwrite these fields" events that can only be used for their original purpose? To me, the reason not to use event sourcing is more that the tooling and developer experience is just really poor - and so decisions like the above, while valuable to think through directly, rapidly become overwhelming. Visualizations of system state are only as good as the code you bring yourself. I'm hopeful that people building tools on top of things like https://materialize.com https://materialize.com will start to change this though!

_3u10 5y ago

Event sourced systems are actually great, as long as they aren’t branded as such. Most of the time it’s totally stupid and the state of the system isn’t reproducible anyway unless the event code is never modified.

mr_tristan 5y ago

This seemed like a great rundown on why event sourcing is complicated: https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-...

bsder 5y ago

Event sourcing is decent when you ingest a lot of things that are mostly one way and immutable once they come into your system. If you have bidirectional communication, you wind up contorting yourself into a pretzel to bury "state" into your event streams.

wrwatson 5y ago

The first rule of data modelling is that you should model only what you care about. A good model allows you to store and retrieve what you need to meet your requirements. Maybe you care about all the events that have ever happened on your incredible journey to reach a list of the customers you have today. Or maybe it would be sufficient to have been mutating a customers table all along. If that is sufficient, then it would be faster and more straightforward to have done so.

mistahenry 5y ago
This is why I always like to have a `status_history` or `audit` table. You don't have to have event sourcing to still want a trail of who changed what in the system when.

holoduke 5y ago

Extra layer of complexity. More development time. More tech dependencies. Don't use it when not needed.