CQRS – Scalability
Scalability is one of the several different benefits you gain from applying CQRS and Event Sourcing to your application architecture. And that is what I wanted to take a closer look at in this post.
One of the first obvious ways to increase the performance of your system is to split the Command from the Query side by using a service bus or just a simple queue. So instead of one machine being responsible for both responsibilities you now have 2 machines.
Then you also get the ability to measure more precisely what the actual bottleneck is, normally your application queries for data many times more then that it is executing behavior. And there are already many well known approaches for scaling your reporting database so that is not what I would like to talk about, but I guess it is clear that this side can now be scaled-out individually from the command side.
Now the command side; because even if this is used many times less then the query side, the actual behavior may take much more time and or processing power.
There are two natural ways of splitting up the domain, the first one is by Aggregate Root type, so you can choose to place a single (or multiple) Aggregate Root type on a different server. The second way is by splitting-up a single Aggregate Root type by the Identity each individual instance has. Think of for example about splitting them up depending on the last number of the Id, even versus un-even.
So who decides? The decision needs to be made by the process that accepts the commands and passes them on to the command handlers, these command handlers can then be running on different machines and each machine may even have it’s own Event Store.
This is a very flexible way of splitting-up your system into different components, and because of the Event Driven Architecture basically build-into this approach you will be able to trigger other behavior on different Aggregate Roots without added trouble.
>>gain from applying CQRS and Event Sourcing
In what way does eventsourcing brings scalability?
AFAIK, The deal with eventsourcing in CQRS is tied to the fact that it can help rebuild the reporting stores and is easy to deal with if you are already raising events.
e.g. If you applied CQRS w/o eventsourcing, you would still be able to scale just as much (?)
Or am I missing something?
@Roger Alsing
You are correct that you gain a lot of scalability by using CQRS without Event Sourcing, but I would like to argue that splitting your AR’s to different servers (including the persistence of them) would be easier when using Event Sourcing. But this is not really true of course
So yes you are correct, but I feel more comfortable with the three last paragraphs done using Event Sourcing.
I’ve been immersing in Udi’s CQRS articles recently, which are about scalability as well. The major point in your article is the idea about splitting-up aggregates on the identity basis, which according to DDD, might seem to be obvious. For me, it wasn’t. This paradigm makes the scalable CQRS-DDD pair much more readable and elegant. And probably scalable, as well
Hi Mark,
nice one, Mark!
Greg explained a rather nice scaling option during his training a while ago. It would, as you state split up aggregates based on their ID. But instead of having a fixed hashing mechanism to find out which server would handle the request, he added a “router” in front of the servers. This router knows which aggregate should be handled by each of the machines. That machine would keep the current state of the aggregate in a cache. Therefore, the event store is only written to, and hardly ever read (only when another server needs to take over in case of server failure). A single event store in the back (highly optimized for writes) should then allow you to scale to a large amount of command handling servers.
When the server crashes, any other server can take over by reading the events from the store and storing the result in his cache. The router decides which machine takes over.
This architecture allows for large-scale low-latency command processing.