Comments on: CQRS – Scalability http://elegantcode.com/2010/02/09/cqrs-scalability/ Wed, 28 Jul 2010 21:28:29 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Allard Buijze http://elegantcode.com/2010/02/09/cqrs-scalability/comment-page-1/#comment-54906 Allard Buijze Wed, 31 Mar 2010 14:23:07 +0000 http://elegantcode.com/2010/02/09/cqrs-scalability/#comment-54906 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. 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.

]]> By: Szymon Kulec http://elegantcode.com/2010/02/09/cqrs-scalability/comment-page-1/#comment-53545 Szymon Kulec Thu, 11 Feb 2010 20:22:29 +0000 http://elegantcode.com/2010/02/09/cqrs-scalability/#comment-53545 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 ;-) 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 ;-)

]]> By: Mark Nijhof http://elegantcode.com/2010/02/09/cqrs-scalability/comment-page-1/#comment-53532 Mark Nijhof Thu, 11 Feb 2010 12:18:35 +0000 http://elegantcode.com/2010/02/09/cqrs-scalability/#comment-53532 <a href="#comment-53531" rel="nofollow">@Roger Alsing</a> 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. @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.

]]> By: Roger Alsing http://elegantcode.com/2010/02/09/cqrs-scalability/comment-page-1/#comment-53531 Roger Alsing Thu, 11 Feb 2010 12:02:48 +0000 http://elegantcode.com/2010/02/09/cqrs-scalability/#comment-53531 >>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? >>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?

]]>