The pros and cons of the CQRS architecture pattern

Having a grasp of common architectural patterns is essential to designing software architecture at scale. Using them not only saves time but also ensures a reliable implementation of your design. There’s no need to reinvent the wheel when there’s an architectural pattern available that applies to an architecture you’re developing.

The following is a brief overview of the CQRS architectural pattern.

[ Download An architect's guide to multicloud infrastructure. ]

Understanding the CRQS pattern

The Command Query Responsibility Segregation (CQRS) pattern separates a service’s write tasks from its read tasks. While reading and writing to the same database is acceptable for small applications, distributed applications operating at web-scale require a segmented approach. Typically there’s more read activity than write activity. Also, read activity is immutable. Thus, replicas dedicated to reading data can be spread out over a variety of geolocations. This approach allows users to get the data that closest to them. The result is a more efficient enterprise application.

Separating write from read activity also allows Enterprise Architects to create a variety of read databases, with each database optimized for a specific purpose.

Pros

• Separating write activity from ready activities allows you to use the best database technology for the task at hand, for example, a SQL database for writing and a non-SQL database for reading.
• Read activity tends to be more frequent than writing, thus you can reduce response latency by placing read data sources in strategic geolocations for better performance.
• Separating write from read activity leads to more efficient scaling of storage capacity based on real-world usage.

Cons

• Supporting the CQRS pattern requires expertise in a variety of database technologies.
• Using the CQRS patterns means that more database technologies are required hence there is more inherent cost either in terms of hardware or if a cloud provider is used, utilization expense.
• Ensuring data consistency requires special consideration in terms of Service Level Agreements (see the CAP theorem).
• Using a large number of databases means more points of failure, thus companies need to have comprehensive monitoring and fail-safety mechanisms in place to provide adequate operation

[ A free guide from Red Hat: The automation architect's handbook. ] 

Putting it all together

CQRS is a popular architecture pattern because it addresses a common problem to most enterprise applications. Separating write behavior from read behavior, which the essence of the CQRS architectural pattern, provides stability and scalability to enterprise applications while also improving overall performance. Choose it for those times when contention over read and write access overwhelms your systems and you're willing to make the investment that's necessary to address the issue. For a deeper dive, read our illustrated guide to CQRS.