From the information given, it is hard to give a proper answer. So I could only provide some thoughts:
The web app should have 100% up time
This is pretty hard to achieve. Even in a one machine local scenario.
You have to fight power outages, failing hardware etc. And as soon as network is involved you have more failing parts, not to speak of the internet and flaky connections.
To throw in some numbers:
- 99.999% availability means 0.87 seconds per day unavaiable
- 99.99% availability means 8.64 seconds per day unavailable
Taken from Google's SRE Book
So even if you could guarantee 99.99% availability on your part, the question is, whether the network the customer uses, is that available.
To decrease network problems you would need some kind of redundant network access for every customer.
A web based solution is good because no user installations are needed
That's true, but comes at the cost of hard(er) to achieve availability.
Some of the data fetched from central database are read-only and are shared between clients
Say you do an on premise installation:
- how were you doing upgrades?
- how do upgrades effect your goal of availability?
- how to deal with different update speeds in terms of consistency? Customer
A has an up to date version of your database, while Customer
B has not, since she/he is still updating?
So, even if you go for an on premise strategy with some "smart updates" the problem of consistency should be thought through.
Clients maybe store their billing or anything else to a central database
This is another interesting topic. Even if you manage the read part with an on premise installation of your data, the network problem for writes stays the same: unreliable connections.
What are the criteria for writes to be accessible by others?
As long as no other than the customer itself needs to have "immediate" access, you could defer the updating part.
How can we handle hybrid online and offline mode when the Internet connection is lost?
Regarding the "read part":
Do an installation of the DB on premise. This is the only chance to rule out network issues. Updates will be one-way and simple: As soon as network is available, updates will be pushed. Problem: eventual consistency.
Regarding the "write part":
Write operations could be queued and delivered when network is available.
When no other customer depends, you have no problems. But when others depend on the data published, you have again the problem of eventual consistency.
Is there any known method?
Yes and no.
There are several patterns available, but no one size fits all solution.
To give good advice, the concrete scenario has to be known and the tradeoffs you/your customer are willing to accept.
Should we sync updates of database into local customer computer and work with that?
As written above: That seems the best solution so far.
One scenario I could think of would be to use a tablet as target platform. These are cheap devices, so your customer could afford more than one (buying or renting). More than one device increases redundancy in case one device fails to work. Devices could be connected via WiFi and 3/4G redundant to decrease probability of network issues.
Perhaps it would make sense from a security perspective, that you lock down the devices to your usecase, to prevent accidentially installed malware from acces to your data.