What is a good software architecture for POS with offline mode?

Question

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.

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.