I'm working at a startup and we're starting to use event sourcing and CQRS a lot more in the replatforming of core components of the application with kafka for

I'm working at a startup and we're starting to use event sourcing and CQRS a lot more in the replatforming of core components of the application with kafka for an event log. Personally, I find these patterns and approaches coupled with sound domain modelling to be perfectly fine. There is some technical overhead for event sourcing so some places we do not use a journal but instead persist current state but we still emit events and do interesting things with those events. CQRS is pretty safe if you're investing into event driven architecture across your organization. You don't need to use both - one or the other is okay too. I wouldn't have designed this system any other way - there are so many opportunities to do interesting things with the event stream that we discover almost daily. Event sourcing is more dangerous and you need to have some really sharp people around to fix issues that come up and make it hum. We have multi-million line logs and I've had to spend some time going through open source libraries and changing implementations for projections from the log that were creating contention and performance issues, as well as modifying how the open source libraries recover to paginate through the events. All in, we can now recover from json in postgres at a rate of 20k events/s (although usually we recover from snapshot!) and we can tear through thousands of commands a second in the running system. After these hurdles, everything is contant time or logarithmic so we can handle orders of magnitude growth without any issue. One day we'll have to flip our aggregates to have a clean journal. It's just life in engineering though - software isn't an event, it's a process so if you want to get the gains sometimes there are some costs. As long as you are smart about your choices and have a good team, you can make anything work. I'll add that the existing stack uses ORMs/active record and the performance overhead of all those damn queries is now too expensive so we're building some screaming fast Eventsourced and commandsourced apps SPECIFICALLY TO GET AWAY FROM THOSE TRIED AND TESTED CLASSICAL PATTERNS. Mind you, we could make the existing application hum too with some careful analysis - I'm not saying one is better or worse, just that they are both equally viable with some smart minds around and good decisions being made. DDD is never a bad thing and ES/CQRS happen to be a reallly incredible fit in spaces where the domain is central as you end up very easily discovering you can have pure and beautiful domain models when you think in commands and events. I'll just leave a caveat that, while I think we're having good success with the decisions, we also work in a domain with enough complexity that we get a lot of benefit in how ES acts as a heuristic in our modelling. Doing the same with a shopping cart may be overkill.