Command and Query Responsibility Segregation (CQRS) — architecture style
In a common approach, we’d normally handle both query and updates operations within the same endpoint, service logic and then rely on multiple repositories to persist data to the database. Some times, it can be complex to query from repositories all the data required in respond to the user experience design.
Most of time, we have a database that serve both query and update operations (that also counts for microservices). As a consequence, we would have complex join queries, perform simple CRUD operations, or process very complex business processes with data mutation. Typically, when performing operations, we would need to make complex validations and apply some business logics. In most systems, we would need to implement complex operations, this will cause to lock other operations to guarantee integrity and consistency.
That leads to a complicated situation where transactions may block queries for retrieving data. Besides that, even complex queries having joins are also inefficient. That makes things difficult to scale. In order to solve the performance issue with concurrent access to data from a data source, we may require a one or a few layers of cache to reduce the response time. Another…
