And important property of it is that client should roll-back the change if the asynchronous action fails eventually.
Moreover, the downside is that it can give the false feeling to the user that something was saved. You click save, synchronously you show "saved", and make an async background save, which fail for whatever reason.
@mitar when implemented properly, the local "save" should be persisted. Even if the app crashes, it should still be stored locally, so it can be synced in the background or at anytime later. And in case of a conflict, both versions should be available on the server, so no data gets lost, and conflict resolution can be done on any devise by the user. If user input is required for conflict resolution at all.