The catch with CQRS is that it isn't widespread enough that everyone recognizes its shortfalls, and the upsides are really easy to convey:

- Excellent auditing abilities

- "time-traveling" debugging (you get the entire history of what happened)

- Easy backup abilities (append-only stores are objectively easier to backup)

- Datastores tailored to your querying requirements (say bye to monstruous SQL queries)

These are the things you see on CQRS-related websites. Then you decide to try it or to research conference talks and such and you find out the downsides:

- Data deletion is now a PITA (and you need it if only for legal reasons)

- Doing actual transactions (in the ACID sense) is now somewhere between hard and impossible

- Welcome to the magic world of non-linearizable datastore operations. Here be dragons.

- If you make a mistake (wrong event / wrong data in an event) you will suffer from it greatly, possibly for all eternity.

I think you're speaking more about event-sourcing than CQRS. CQRS is a generic concept that's only about separating writes from reads. It's useful paired with event-sourcing but on its own it does not suffer these specific drawbacks.

Another problem with event sourcing is that there is no easily definable concept of a "field" that can be read from and written to using a named address (contrast with a SQL table column identifier). For a given aggregate, you'll have a single command service that writes a set of "fields" and an unbounded number of query services that receive a copy of that "field" from the event stream and can transform it in any imaginable way. Your "field" may be renamed and moved around through its journey from your command service's API request body to your event's serialized form and to your query service's internal data structures and its final resting place on the query service's persistence data store (mongodb or SQL table or whatever).

To identify a field, it's best to use its writable address, and you'll need to come up with your own identifier namespace and naming convention to represent those addresses.

> I think you're speaking more about event-sourcing than CQRS

True. I was reading to the comments here and yes, most of them were focusing on the Event Sourcing part of Wokenkit, not the CQRS so my mind got tricked.

Great overview! I’ve hit these problems. I wish people would be more honest and upfront about how it’s really hard to implement these patterns and operate them.

That said, I think that’s what frameworks are all s about. I’m using Kafka Streams which is an amazing foundation for CQRS/ES but the absence of a framework for it means you need to implement all these models/patterns by hand. It’s pretty hard.

Most apps need migrations. Isn’t the best migration the one you didn’t do? If you have CQRS and event sourcing, you can create views like hot cakes.