It sounds like you are looking to implement push notifications from your back-end service to each front-end client.
Two options come to mind:
- WebSockets will allow your clients to maintain a persistent two-way communication channel with the server. Updates on the client can be sent along the persistent channel, and when the web-server receives a change to the data store, it can propagate it out to each connected client. Using this, each client will probably (more on this later) have the most updated data whenever it wants to make a change to it
- HTTP Long Poll is an older method (that works quite well) that utilizes HTTP with long timeouts to accomplish something similar to push updates. Each client opens a HTTP request for some resource and has a long timeout (say, 2 minutes for example). When something changes, the server will respond with the new data, otherwise, it will wait for the full 2 minutes before sending a 304 NOT MODIFIED response to the server. In this way, the client can get notifications pretty quickly, but without constantly polling.
Both of these ideas can be read up on here: https://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
Both of these options suffer from the possibility that two clients will want to make updates at the same time, and one my overwrite the other. In this way it is easy for your data-store to become out of sync or have logical inconsistencies in it. If you would like to avoid this, as pjc50 mentioned, you may want to consider using a distributed database.