I worked on an event sourced system once, many years ago.
I'm not saying I hate the separation of write and read models, and all the challenges that brings (heck, the platform I'm working on now does that, and it's not a big deal), but it was massively bloated and overly complex for a system that would collect some data from users, submit it to a panel of third party services, and display results back to those users.
The reasons for going this route were complex, and not entirely clear to me, although I can pick on two: firstly, they'd run into performance and scalability issues with their existing CRUD-ish SQL Server-backed implementation and, secondly, Thoughtworks told them it would be a good idea.
I don't want to handwave this away but I've encountered enough insoluble SQL Server performance issues over the years to be confident those issues could have been solved much more simply (and the same is likely true for Oracle, Postgres, et al). I'm not suggesting that intractable performance issues don't exist on relational platforms, just that most times people think they've encountered one, they're mistaken.
Would I use event sourcing again? Maybe. But I'd need a really strong use case for it, and I'd certainly kick the tyres on any technical organisation that was using it before I joined.
I'm not saying I hate the separation of write and read models, and all the challenges that brings (heck, the platform I'm working on now does that, and it's not a big deal), but it was massively bloated and overly complex for a system that would collect some data from users, submit it to a panel of third party services, and display results back to those users.
The reasons for going this route were complex, and not entirely clear to me, although I can pick on two: firstly, they'd run into performance and scalability issues with their existing CRUD-ish SQL Server-backed implementation and, secondly, Thoughtworks told them it would be a good idea.
I don't want to handwave this away but I've encountered enough insoluble SQL Server performance issues over the years to be confident those issues could have been solved much more simply (and the same is likely true for Oracle, Postgres, et al). I'm not suggesting that intractable performance issues don't exist on relational platforms, just that most times people think they've encountered one, they're mistaken.
Would I use event sourcing again? Maybe. But I'd need a really strong use case for it, and I'd certainly kick the tyres on any technical organisation that was using it before I joined.