Offline sync and event sourcing

Question

The CRUD-based part of our application needs:

1. Offline bidirectional "two-way" syncing
2. Ability to modify data until ready and then "publish".
3. Audit log

Event Sourcing (or the "command pattern") is what I'm looking at to accomplish these items. I feel comfortable with solving 2&3 with this, but not clear for item one, syncing.

If timestamps are used for each command (if needed), do the offline commands need to be applied to master system as they would have been in real-time (coalesced), or can I just consider them applied as happening at the end of any command (with a more recent timestamp)?

Any basic algorithm description for command-based sync would be helpful.

Foliose

Useful articles for me are touchlabblog.tumblr.com/post/33710233787/… and docs.google.com/file/d/0B_BG7hBPKUxaeVFTSUI4Ylp3VjQ/edit – Foliose

Answer 1

You'll want to review what Greg Young has to say about CQRS and Occasionally Connected Systems

Commands need to run on the system of record at the time they are received. So your offline client can work with its locally cached, stale, copy of the record, and queue up commands. When connected again, the client updates it's copy of the system of record, reconciles its queued commands with the new state of the world, and then sends the new commands to the system of record.

Greg's talk sketches how the command reconciliation worked (basically, by looking at the events the provisional commands generate, and looking for conflicts with the events recorded by the system of record). The talk strongly implies that domain experts will want event conflicts to be resolved in specific ways.

Torrential

That's what i am looking for thanks to you @Torrential – Vlad

One problem with "simply" checking for conflicts between provisional events and those received from the system of record is that it identifies only the commands that will produce such conflicting events... but other pending commands (that do not themselves produce conflicting events) may have some causal dependency on such a conflict—but it's extremely difficult to capture this, as one does not know upon what information the user was relying when the command was issued. So do you mark as (potentially) unmergeable every single command that was issued after the first one that conflicts? – Overbear