Re: Clustering a DDD/CQRS/ES app

The model is most similar to
http://readwrite.com/2011/02/10/megastore-googles-answer-to-no . There are
some pros and cons to the model. I think if you go more than 3 servers you
will eventually build a paxos state machine.

Pros:
scalability
consistent
allows writing to local node

Cons:
can not write very many events/second to any given stream (they will start
deadlocking). You could get around that by mapping messages for a given
stream to a single node but that removes #2 above and limits #1.

Cheers,

Greg




On Mon, Apr 8, 2013 at 11:16 AM, Rickard Öberg <[email protected]>wrote:

> On 4/8/13 16:12 , Greg Young wrote:
>
>> Can I get a dirty read in the middle?
>>
>
> From the repo: nope, because the aggregate is locked while the event is
> being sent to the eventstore. Applying a command is a synchronous
> operation. The handler is a function: Function<CommandContext<?>,**InteractionContext>,
> i.e. submitting a command will wait until it has been successfully applied.
> On my local dev machine it's roughly 2-5ms for the whole REST call from
> start to finish.
>
> From the view: nope, because the eventstore will drop faulty events as per
> previous algo, so will never be applied in the underlying database(s)
> (Neo4j and Lucene in my example).
>
> Teh awesome?
>
> /Rickard
>
>


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