I have a software for small delivery stores (pizzeria, Japanese, etc) here in Brazil running on a few dozen customers and have the possibility to expand it to many more customers after evolving it to a full POS (Point of sale) software.

However, there is a critical feature we've been struggling to develop: an offline mode. Internet in Brazil is not reliable for commercial use so its usual in some regions to have problems from a few disconnections a week up to a disconnections for 0-90 minutes every other day.

The software is made in C#/Windows Forms and the database is MySQL hosted on Azure. The customers connect to the same database and every table has a CompanyId. It is strategic to have a database online rather than a MySQL server in the customers local network.

I've done a good amount of research but didn't find a solution or a direction so far.

We took one approach: consider the installation would also install a MySQL and download (if any) the company data, the software would connect to the local database and every a few seconds would make the changes from the local to the cloud database. But it proved challenging and had impact in the code design (can't do from the scratch due to current customers).

Right now we would consider make this mode from the scratch and the migrate previous.

1 Answer 1


The default option I see a lot of people taking is to have a local database with the same structure and sync it with the server. This is quick to setup and there are various tools and libraries you can use to implement it.

However, I don't think this is a good approach.

I would use a queue/event store based architecture where actions are stored locally until a connection is available and then processed. For example, lets say that every time you make a sale you have to update the stock level, which must be done on the server.

When the sale is complete you create a "update stock level" task, with all the required information and stick it in a queue (which could be a simple database table)

You then have a background process which monitors the queue and, if a internet connection is available, takes items off the queue one at a time and sends them to the server for processing.

This enables you to show the user what and how many tasks are waiting to be actioned and allows you to control the logic used when a conflict occurs. ie there's no stock left, but the sale completed some time ago.

Also, it allows better separation of concerns. The local database can be a completely different structure to the server based one.

  • The database is a good approach if you know the user(s) are going to be offline for an extended period of time. For example, I worked on an application once when sales people would visit doctor's offices. So, they were offline during the visit and then online when back home or at office. If the connectivity is intermittent then I like the queue/event store approach better to cover those situations.
    – Jon Raynor
    Jan 12, 2017 at 15:23
  • Thanks Ewan for the answer. That was really helpful. @JonRaynor, is there an alternative if the users are going offline for a small period of time?(slow connection or disconnected up to 15min?) Jan 12, 2017 at 16:58
  • I think Ewan's answer of an event store would work in those scenarios. It could be just pushing those events to memory and/or to local disk and then when back on line processing the events, similar to a transaction log concept.
    – Jon Raynor
    Jan 12, 2017 at 20:33
  • 1
    Does a pizza ordering poi make sense if you cannot garantee that the order reaches the order service within a few minutes? I would just display the message "Sorry, internetconnection to transfer the order is currently not available. Please try again later" when the connection goes offline
    – k3b
    Jul 2, 2019 at 10:17

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