I need to develop a point of sale app that will be used on several locations. In every location it will be use a single database and it will be, in another location a master database with all cashflow and inventory moves. The restriction is that the available internet connection between nodes is very poor, so in certain way all locations the most of the time will be working offline, that is, without internet connection, and when the connection will be available again, will resync with the master database.
I was thinking to develop an architecture with a single database in each location, and implement replication between the master db and others db, but when the internet connection go offline in the nodes, they need to continue working on offline mode until internet connection will be available again. I was not sure if replication is the correct approach to this schema, because the nodes will be inserting and updating the local db and need to propagates the cashflow data and inventory data to the master db and to the other nodes.
what will be the right approach in this schema?
I plan to use dotnet and MSSql Server 2k8
Regards
I would consider a queueing system as an alternative to a local database. I’d expect such product to offer features, for automatically starting transmission of messages, as soon as a connection is available. But this is really just a technical issue.
A couple of things you should consider when building your architecture:
are there limits on how out of sync your application is allowed to get? E.g. when your app hasn’t connected to the master for a month, is still supposed to run without a hitch? You must allow for appropriate storage capabilities on the client, and ways to escalate the issue, when a threshold is met.
You are bound to get conflicts. E.g. when you accept an order, it may sit for 4 hours on the client, and when it finally reaches the server, the product ordered might not even exist anymore. Get creative on what might get wrong and define how these cases are supposed to get resolved.
Make sure you have decent logging, especially for stuff that is crossing the connection. You should be able to easily find logging information on server and client which relates to the same business transaction.
Make sure you can test you components, without the others.
And of course in a distributed system you have to access how trustworthy a client is. I.e. how can you assert that a message coming from server or client is really coming from a client and is not forged by somebody or something else.
Clearly quantify how much bandwidth you have available, so you can make sure that all the required data actually fits in. Many small transactions might help, since they are less likely to get interrupted by a interruption of connectivity.
You also might find this book helpful