Event Ordering, Concurrency, Client Reconnect Sync, Aggregate Hydration, & Event Snapshots

[aadamsx]

Event Ordering, Concurrency, and Client Reconnect Sync:
Are you ordering the events as they come into the event store, how are you keeping track of the ordering of events when you have multiple clients working on the same data? ... for example you have two users both changing customer information, the first makes a change, that means the second has stale data, then second one makes a change to customer data, but not the same customer data as the first user -- are you keeping track of the event orders, how are you handling concurrency in this case -- say a third use comes online with the customer screen up after being offline for a while, how do you sync up what's happened since he's been offline?

Aggregate Hydration and Snapshots:
How are you populating your aggregate root from your event source with you have 1 million events or more? I understand you're using snapshots on your MongoDb that stores events -- I don't mean taking backups, I mean instead of hydrating your Aggregate Root from your ES from the bottom up, you hydrate from the top down to a "snapshot" or versioned pointer in MongoDb?

Thanks!

[adrai]

ok.....
for concurrency stuff there is a revision...
the domain handles a command completely atomic and increments the revision on the aggregate and on the resulting event... so if the second user sends a command with the previous revision the domain will reject it... etc...

the snapshots are completely storage agnostic... so they a snapshot is just a 'freezed' point in time of an aggregate state...