CODEWITHSUNDEEP
domain-driven-designcqrs
Jonas Geiregat
Jonas Geiregat

Reputation: 5442

How can CQRS contribute to more scalable applications

Lately I've been reading a lot on CQRS architecture. One of the foremost points stated on why one should use CQRS is scalability.

Now I don't quite understand how this can work.

Let's say you have your typical CQRS application design.

It's often stated that having a datastore for querying and one for handling commands would make your application more scalable. But how can this work if the second datastore that stores the event data needs to respond to the query requests and also constantly needs to update iteself based on the incoming events ?

Why not have one datastore where the commands are stored and where the query side can re-use the stored data for fetching it's result data ?

Upvotes: 6

Views: 1099

Answers (2)

inf3rno
inf3rno

Reputation: 26137

Two Datastores
One for the Command Side
One for Query Side
When a Command has been processed an Event is send which could update the second Datastore

This is CQRS with ES (event sourcing), don't confuse things!

Event sourcing is about storing domain events raised by handling the incoming commands. So you can play them back any time you want. This makes the read side more flexible, because you can any time change your read database structure, and after that you just replay the domain events instead of writing some fancy migration code. Storing the commands is not okay, because you don't necessarily have the same environment (for example different time on the server), so you cannot replay them safely. Command storing is just for logging purposes...

Command and Query responsibility segregation is about dividing the incoming requests into two groups: write (command) and read (query). The basic idea behind this was, that you don't have to use the same ORM entities by reading your relational database as you use by writing it. So you spare the object-relational mapping by the reads, which makes things faster. Later it went through an improvement, and now it means that you can use multiple databases by the read part, each one specific to a group of queries. For example, if a graph database, like neo4j fits better to some of the queries, then you add a neo4j database instead of using the same relational database to serve those queries. This can make things a lot faster...

Upvotes: 3

MaxSC
MaxSC

Reputation: 4758

You might find interesting to read this old blog post from Greg Young himself, where he explains what exactly CQRS is.

CQRS is not about having 2 different stores, but, as stated on Greg's article:

CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query

What you describe here is more Event Sourcing.

Now back to your question: How can CQRS contribute to more scalable applications? Greg answers that as well:

CQRS allows to host two services differently eg: we can host the read service on 25 servers and the write service on two. The processing of commands and queries is fundamentally asymmetrical, and scaling the services symmetrically does not make a lot of sense.

That's it!

Upvotes: 14

Related Questions