Re: Clustering a DDD/CQRS/ES app

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.