<p>You may want to review Greg Young's talk on <a href="https://skillsmatter.com/skillscasts/1980-cqrs-not-just-for-server-systems" rel="nofollow noreferrer">occasionally connected systems</a>.</p>
<blockquote>
<p>The problem is that the commands are fire-and-forget</p>
</blockquote>
<p>How do you understand &quot;fire-and-forget&quot;?  If the model isn't allowed to reject the commands that are dispatched to it, then the messages you are sending are <em>events</em>, not commands.</p>
<p>The usual implementation of the write model in CQRS is that commands are linearized (handled one at a time).  Commands are expected to ensure that their pre-conditions are met.</p>
<p><code>Compare-And-Set</code>, rather than <code>Set</code>.</p>
<p>In its simplest form, the commands specify the initial version of the aggregate they are going to modify, in much the same way that conditional requests in HTTP specify <a href="https://www.rfc-editor.org/rfc/rfc7232#section-3" rel="nofollow noreferrer">preconditions on the resource</a>.  In the case of a race condition, with multiple commands trying to change the same part of the model, one command would win, and the loser would be trivially rejected.</p>
<p>Better (but more work to implement) would be to implement a sort of second chance for the losing command -- building into the model sufficient understanding that it can determine whether the changes induced by the two commands conflict.  If they don't, then you just chain them together.</p>
<p>An alternative approach is to allow both writes to happen, and accept that there is a conflict.  Think about the way a source control system works: I've committed history 1-2-X, you've committed history 1-2-Y, and now there are two alternatives until somebody reconciles them with a merge.</p>
<p>That approach is roughly in alignment with Udi Dahan's central point in his essay <a href="http://udidahan.com/2010/08/31/race-conditions-dont-exist/" rel="nofollow noreferrer">Race Conditions Don't Exist</a>.</p>
<blockquote>
<p>A microsecond difference in timing shouldn’t make a difference to core business behaviors.</p>
</blockquote>
<p>If your views are being built from lists of events (as you describe here), then one place to start with with a <a href="https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type" rel="nofollow noreferrer">CRDT</a> of a list.  Mark Klepmann describes a <a href="https://arxiv.org/abs/1608.03960" rel="nofollow noreferrer">JSON data type</a> <a href="https://news.ycombinator.com/item?id=12303100" rel="nofollow noreferrer">(hacker new commentary)</a>.  That doesn't get you &quot;no conflicts&quot;, but it does get you the property that two users who see the same individual events necessarily seem them in the same order (if there is a problem, then everybody is seeing the same problem).</p>
<p>But Greg's approach is probably simpler to implement - authors work with a local copy of the shared model, and interact with it, but that shared model is an approximation, and commands that cannot be reconciled by the book of record are returned to the author for manual mitigation.</p>
CQRS and commands debouncing
<p>I have the following task:</p>

<ol>
<li>Our current architecture is Web SPA with CQRS and MVVM. We have
commands, queries and SingnalR as message bus.  </li>
<li>Users can select, move, resize divs on the same workspace from several web browsers simultaneously.  </li>
<li>Each div is binded to the approprite ViewModel. Each ViewModel has it's own query to refresh. Each ViewModel subscribed to business events and refresh the whole state after it.</li>
</ol>

<p>Lets image that User is doing the following steps:</p>

<ol>
<li>Select div (SelectWidgetCommand sent)</li>
<li>Move div to x=10. (ChangePositionCommand sent)</li>
<li>Move div to x=100. (ChangePositionCommand sent)</li>
</ol>

<p>The problem is that the commands are fire-and-forget and the User may receive event WidgetSelectedEvent during the Step 3 but the ChangePositionCommand may not be handled yet. So the User will receive the old x position and the div will move to the old position.</p>

<p>What is the best practice to handle this kind of issues?</p>

<p>What we are now doing is splitting the DivViewModel into two divs: SelectionViewModel, PositionViewModel. Each ViewModel has it's own query to refresh and different events to handle. Also we consider using debounce and rolling buffer for commands handling.</p>