1. The command will be sent to the server.

2. The command will be performed on the local database, but backing up the original local DB state so that it can be reverted if needed.

3. Immediately, any helper functions used by templates which rely on data from the DB will react to the change in the local DB and inform their template instances to update just the relevant part of the DOM.

4. The server will eventually get the request, and authorize it based on allow/deny rules.

5. If the command was allowed, the server will update the actual DB, and use MongoDB's oplog to notify all other server instances that the data has changed.

6. Server instances will send the changed data down to all subscribed clients, which update the state of their local DBs, causing the templates to re-render the relevant parts of the DOM.

7. If the request was denied on the server, the server informs the requesting client, and the client patches up its local DB to the actual DB's state, also reverting the DOM state.

So you have built-in latency compensation and full-stack reactivity by default. The client anticipates the server's response, making the application feel extremely responsive. But if something goes wrong, the client patches itself up with the actual result. Of course you can avoid latency compensation altogether where you don't want it - just avoid using the isomorphic API on the client and use RPCs instead. The servers will still inform the other server instances and push the changed data down to all the subscribed clients, but the requesting client has to wait like everyone else before the DOM is updated.