Why don't more developers use event sourcing?

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)

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.

There are some complexities such as 2-phase commits and rollbacks in a distributed system. Nothing blocking, but definitely not as simple as CRUD.

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.

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.