I'm building a mobile, in which the user is able to create,modify and delete entries in a database. There are multiple screen where some of the entries are displayed: (here are some examples, not exhaustive)

  • Screen with the list of the entries
  • Screen with details about one particular entry
  • Screen with some statistics calculated from the entries

My question is, taking into account the reactivity we want with a mobile app (I want the data on screen to be always updated with what the user does), should the app:

  • keep a local (I mean on run time) version of the data to be responsive, and it often update this local version from the database, but asynchronousl, or
  • always fetch data from the database directly (even if we have to wait for the database)

What would be the 'best practice' ?


2 Answers 2


should the app keep a local (I mean on run time) version of the data to be responsive and it often updates this local version from the database but asynchronously or always fetch data from the database directly (even if we have to wait for the database).

tl;dr: As usual: it depends :-). You need to decide which is more important - consistent, up-to-data data or responsiveness and availability.

What you are describing is basically one of the unavoidable compromises you must make in a distributed system (distributed, because you have a local client and a remote server/database):

  • keep data local - more responsive, but risk showing old data, and encountering edit conflicts
  • always use remote data - less responsive, relies on server being online, but no risk of old data, less risk of editing conflicts

Basically, this is a special case of the CAP theorem: If you want

  • Consistency (no stale data)
  • Availability (no errors)
  • Partition tolerance (can tolerate server being down)

then you can only have two :-).

In practices, there are various possible solutions.

  1. The simplest to implement is to just always use the remote DB directly. That relies on a good internet connection and the server being online, but is simplest, because you offload a lot of work to the server.

  2. Another solution is to have a local copy/cache of the database, which is synchronised with the server. That way people can work locally, and offline. For example, most Email clients work like this (using SMTP and POP3/IMAP for synchronisation). This is more complex, because of the local copy and the synchronisatioin, but allows the user to decide the tradeoff themselves - work offline, and live with old data, or work online, and get current data.

I would recommend starting with 1), then "upgrade" to 2) if it becomes necessary.

Finally, note that in all cases you will have to account for editing conflicts (unless you only support a single user and session). Two users might load the same entry in parallel, then both edit and submit their edit. This is possible even if everyone is online all the time.

To handle this, you either need to lock entries for editing (user-unfriendly, and requires being online), or have some type of conflict resolution (more complex). Again, how to handle this depends on your application. For ideas you could look for example at how merge conflicts are handled in Git, or use a technique like optimistic locking.

  • 1
    Thank you for your detailed explanation! I weighted the pros and cons. As you say, I will first implement a only online solution. For the moment I don't plan on having multiple users accessing the same database. So I think I'm good regarding editing conflicts. Commented Apr 5, 2023 at 20:47

A local SQL database is fast. And since you only need to display one screen worth of data, speed is absolutely no problem.

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.