Ask HN: Why don't more developers use event sourcing?
I have found event sourcing (https://martinfowler.com/eaaDev/EventSourcing.html) to be extremely powerful when building applications, however in my experience CRUD seems to be much more prevalent.
Why do you think event sourcing isn't as common?
There was another post a while back about all the complex problems that arise from event sourcing — problems similar to race conditions that end up being really tricky to solve.
I've always wanted to build a small tool on top of event sourcing, but as long as the app is small it should probably be ok. But if it scales up, there's lots of room for massive errors.
(Sorry I can't find the link)
What sort of errors? You're talking about eventual consistency issues?
I tried coming up with EventSourcing attempts for a large application that’s basically only shuffling around data from n source systems to m target systems (sometime of them are both). I thought ES would be perfect, as we mostly care about changes and where to they came from, not so much about the current state (mostly…) But I am not smart enough. I just could not come up with a way to make it work. I do not understand the darn thing, even after spending hours reading fowlers and others stuff. The basics sound simple enough to me. Store events, not state, generate state from history of events. But does each event belong to one entity, to one type of entities, or is it global? We have a quite elaborate net of things interconnected and reliant on other, changed and provided via vastly different services/protocols/etc.
I think I need some more braincells to understand Event Sourcing.
> does each event belong to one entity, to one type of entities, or is it global
Are you asking about building aggregates in CQRS? Or is this specific to event sourcing?
Were your concerns were with modeling your domain more so than the infrastructure powering the "event sourcing"?
There are some complexities such as 2-phase commits and rollbacks in a distributed system. Nothing blocking, but definitely not as simple as CRUD.
Agreed. When you take on Event Sourcing, you are effectively trading one set of technical problems for another.
I personally enjoy working in an event sourced codebase, but it's most interesting when it is greenfield development. Growing and maintaining such a code base can turn into a headache.
It's an interesting model for a small subset of domains. Within those domains, things get very complex if you need consistency guarantees and non-trivial downstream pipelines to process those events. And maybe most importantly, the majority of developers are working on existing systems, not on greenfield projects where this architectural decision is even on the table.
we have been trying to get this model up and running since a year now. we have had no luck so far. the project has been delayed, my team is frustrated and our architect hippity hoppitied his way out and moved on to the next architecture committee.
what you essentially end up writing is some poor version of something that mimics database replication. This is an extremely hard problem to solve. I would not recommend it unless you have someone leading the team with years of experience writing such a system.
Why did you want to do this in the first place?
as I said earlier, It wasn't my decision, it was the architect, I joined the project much later.
It should be used when it fits the problem to hand. Why do you think it should be more common?
It adds a lot of effort.