Great question, I'm going to C&P a reply I did previously: 1. In memory in the browser tab's process. 2. If available, in the browser's localstorage or fallba

Great question, I'm going to C&P a reply I did previously: 1. In memory in the browser tab's process. 2. If available, in the browser's localstorage or fallback. 3. In the server process's memory. 4. If available, on disk in the server. 5. If in a multi-machine setup, any other connected server that is subscribed to that data set, being in memory (3) or in disk (4) if available. 6. If configured, in a machine log on S3. 7. Persisted to S3, which replicates and shards it for you internally. 8. If configured, in a revision file on S3. 9. If configured, in a multi-region S3 setup, redundantly in many places. (2) is not cleared till an acknowledgment that (7) is confirmed. (1) is not cleared until an acknowledgement that (7) is confirmed or if the tab is exited. In the case of (7) it is no longer the delta/diff, but a snapshot of that current data set with that delta/diff's update. Retries from (1) ~ (5) will happen at various events, if the confirmations are not satisfied. If a conflict has already occurred by (3) the acknowledgement from (5) will include a notification that the value has already been updated, along with the standard delta/diff of that conflicting update being sent down. Meaning (5) does not guarantee that your delta/diff has "won", only that it has been saved or is already outdated. Worst case condition is that (2, 4, 5, 6, 8, 9) are turned off, in which your user's data is as volatile as them preemptively leaving the page (although I suppose you could use an onbeforeunload to warn them) - however this behavior is the current norm for most http post based forms and apps. Actually, pardon me, worst case condition is that everything is offline simultaneously, however this is not really interesting because then users won't even be able to access your app in the first place.