I'm implementing an app that has among other things shared todo lists. I want it to sync in real time. This has to work for "normal" single user items (e.g. user has app opened in 2 devices, doing an update in one device shows immediately in the other device) as well as the shared lists, where all the participants have to receive the update in real time.

I'm not entirely sure which kind of structure is best in order to accomplish this. I was thinking about storing a dictionary of user uuid -> socket list. When users log in or open the app while being logged in, they'll initiate a connection. Here I add an entry or update to the dictionary. When they log out or close the app, the connection is closed and I update the map accordingly. Whenever the app does an update in the server, I look up the affected users, then look up in my dictionary for possible open websockets for these users, and send the updates to them.

Another idea I had, was to associate the connections rather than with the users, with items, like e.g. the todo lists. So again I have a dictionary, but this time the key is the todo list uuid and it has an array of connections ("observers") for this list, where I broadcast wherever the list is modified. This approach is not suitable for the "single user sync" though, here the elements don't necessarily have an own identity, rather associated with the user - so I'm back to the first approach with a dictionary user -> connections.

But before I dive into more details I'd like to confirm if this is the correct train of thought. How is this normally modelled? This is rather a theory question, but in case it's relevant for something, I'm using Play Framework 2.4 / Scala.

  • When you say "real-time," do you mean instantaneously, or do you mean "within sixty seconds or so?" Nov 25, 2015 at 17:14
  • Preferably instantaneously... small delays sometimes are acceptable though. I wanted to use push notifications first but the possible delays where one of the reasons I went for websockets...
    – User
    Nov 25, 2015 at 17:19

3 Answers 3


This sounds like a classic publish/subscribe scenario. I would suggest using a pub/sub design on the back-end (eg., JMS or AMQP) and using a AMQP/JMS->JavaScript framework for your browser front-end. Here's an example: http://www.websocket.org/demos/todomvc/index.html Very straightforward.

  • 1
    This is almost a link-only answer. Can you elaborate a bit? Maybe add a bit more of your own perspective to better answer the question? Your personal insights are important! Nov 28, 2015 at 15:21

If using a subscription based cloud service is an option for your use case you should have a look at Realtime Cloud Storage (the company I work for).

It's a data backend (powered by AWS DynamoDB) with scalable real-time data-sync features. More at http://framework.realtime.co/storage/

We also have an on-line todo demo written in JavaScript at http://storage-public.realtime.co/samples/todo-lbl/index.html#/


Ok I ended implementing publish / subscribe, using websockets. I implemented a set dictionaries for different categories (like todo lists or single-user events), where the keys are the subject (in my case uuid of list or users) and the values the list of subscribers. Concerning implementation details I did this using Play and Akka actors.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.