Re: Clustering a DDD/CQRS/ES app

Ok I have updated the code to do clustering on EventStore level instead. Added support for initial population from other instances in cluster. Works great!

When events are distributed each store checks if version of aggregate in event matches local version+1. If no, then concurrent update has occurred and event is discarded. On instance that caused that event the inmemory copy of aggregate in repo is cleared and REST API reports 409, with option to redo command instead. It has support for etags as well, so long running optimistic concurrency works too, if desired.

For Javaites, see code on Github for details. Feedback is most welcome.

/Rickard

Sent from my iPad

On 6 apr 2013, at 17:29, Greg Young <[email protected]> wrote:

> 
> 
> 
> On Sat, Apr 6, 2013 at 12:26 PM, Rickard Öberg <[email protected]> wrote:
> Thanks for reply on this fascinating topic!
> 
> 
> On 4/6/13 17:19 , Greg Young wrote:
> What happens when your cluster is running 3 versions of software and the
> 3 versions all calc slightly differently?
> 
> Yes that's definitely an issue.
> 
> 
> What if you want to do some for of synchronous integration during the
> processing of a command?
> 
> So basically process the command on the local process and when event(s) are generated distribute that (in my case with HazelCast). What about locking, i.e. if someone else sends commands to same aggregate on another server at the same time? Local locking is trivial ("synchronized" will do), but across cluster?
> 
> Thats the beauty of the model discussed below. What ends up happening in the event store is that there are paxos elections. Distributed locks become forwarding and local locks. 
> 
> 
> 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.
> 
> Yes, that makes sense.
> 
> 
> 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.
> 
> Does this assume that there is no load balancer in front? I.e. you have round robin DNS instead?
> 
> in this case yes.
>  
> 
> 
> /Rickard
> 
> 
> 
> 
> -- 
> Le doute n'est pas une condition agréable, mais la certitude est absurde.