CQRS (Command Query Responsibility Segregation)

What issues are addressed by CQRS?

• Using the API composition pattern to fetch data distributed across numerous services often leads to costly and ineffective in-memory joins.
• Sometimes, the service responsible for storing data uses a format or database that does not efficiently support the necessary queries.
• The need to maintain a clear separation of concerns implies that the service in charge of data ownership may not be the ideal candidate for implementing query operations.

Description of CQRS

💡 You can use another service for query view. It useful when query depends on data from different services.

Pros and cons

✅ Enables the efficient implementation of queries in a microservice architecture ✅ Enables the efficient implementation of diverse queries. Some NoSQL databases have very limited querying capabilities. Using a specialized database for query is often more efficient ✅ Makes querying possible in an event sourcing-based application ✅ Improves separation of concerns The command side and query side are likely to be simpler and easier to maintain. ⛔ More complex architecture ⛔ Dealing with the replication lag. Solutions for this issue: - client updates model by using data returned in command - client updates data by using data in form. Client duplicates server logic.

---

💡 you should use the API composition 202310131459022 API composer whenever possible and use CQRS only when you must.

---

References

1. Microservices patterns by Chris Richardson, chapter 7