Building CQRS systems not only has benefits, it also has shortcomings.

Probably one of the biggest shortcoming of constructing these systems is that the majority of developers are not familiar with the concept, design and implementations. This will introduce difficulties when this approach is chosen in enterprise projects. Unlike CRUD-based systems, CQRS would require additional training and know-how.

Like any distributed system, there are naturally more applications involved in a CQRS system compared to the CRUD approach. As previously described for distributed systems in general, this requires some extra effort. Additionally, an event store is required.

Unlike the figures demonstrated, it is not mandatory to have the command and query sides in two or more independent applications. As long as the functionalities only communicate via events published by the event store, both can reside within the same application. This would, for example, result in a single waiter and chef application that still scales out horizontally. This is a reasonable trade-off, if individually scaling the write and read sides is not required.