Re: Clustering a DDD/CQRS/ES app

So you probably want to distribute the event not the command to all servers
there are various reasons for this including:

What happens when your cluster is running 3 versions of software and the 3
versions all calc slightly differently?
What if you want to do some for of synchronous integration during the
processing of a command?

For dealing with a new server it would just have a durable subscription
(more on that later). When it came in it would start at 0 and move forward.
It would be in a state of replicating until it caught up. A very easy way
to do this for many people is to just run EventStore as embedded in their
process (or hosting it as a separate process on each node). This is exactly
what it will do.

Its also not needed to pin to a server though using keepalives will give
you this 99% of the time. What we do is a quorum of servers have responded
to your write before we say that the write has completed. If you want 100%
assured write/read semantics in all failure conditions you can just read
from a quorum of servers.

Cheers,

Greg



On Sat, Apr 6, 2013 at 5:15 AM, Rickard Öberg <[email protected]>wrote:

> **
>
>
> Hi,
>
> I've been experimenting with a simple app (todo-list manager) where I
> want to try out CQRS/ES with a REST API on top. You can see the code at:
> https://github.com/rickardoberg/cqrs (CQRS/ES library)
> https://github.com/rickardoberg/stuff (todo list app)
> https://github.com/rickardoberg/shithappens (app consuming Stuff REST
> API for automation)
>
> Yesterday I looked into the question of "how would I cluster this?". The
> REST API creates commands and dispatches to a command handler that then
> invokes the domain. So what I did was to introduce a command handler
> filter that uses Hazelcast to distribute the command with global
> ordering into set of servers. All servers get the same sequence of
> commands, process them locally, generate the events, update the views.
> Tremendously simple, and works. The instance that published the command
> gets the result and/or exception from the command handler, and uses that
> to create a REST API response synchronously. If the REST client (e.g. a
> browser) is pinned to a server using cookies it gets a
> read-what-you-write guarantee. Awesome.
>
> The main remaining issue is how to deal with failures, or bringing up a
> new server. Don't quite know the best way to handle that yet.
>
> But my question is: if anyone else is clustering their CQRS/ES apps, how
> did you do it? Where did you put in the clustering, and how do you
> partition and handle failures etc.?
>
> /Rickard
>  
>



-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.