Yup, we've used it that way, and it's easy to implement due to the fact that all changes are expressed as a payload object, which allows you to serialize actions. Optimistic actions (showing the Like when the server hasn't confirmed yet) are built the same way - the stores just need to resolve between the optimistic/offline update and the eventual server response.

This architecture describes how data affects presentation and vice versa. Your question is a bit off, it involves implementation, not structure.

Ok, I also don't quite understand if the Store has any relation to the server-side database.

It's just a store. You could write your implementation to store the data anywhere - localstorage, a REST service, the one in the example just keeps it in memory as an array.

I think you could do this in a Store component which uses a ServiceWorker.