If we have a database system replicated in geographically separate locations... and we want to allow writes on each of them. What is the best way to do that?
For example: A site like expedia.com allows customers around the world to book any hotel.
Say customers in US, Europe and Asia are looking to book a room in the same hotel. We can read from multiple RO instances which are geographically separated (and replicated), so we show the customers that a room is available in that hotel.
Now if all these customers try to book, the easiest way would be to write to a single instance.
Before writing we check every time, if the room is available or not. If it is still available, we write.
In that way once the first request goes through we can reject the others.
But in this way customer in US (where the master instance is located) will have an unfair advantage as it takes longer time for the write request to go over the wire across long distances.
So we will have to allow write to multiple instance.. and then allow some time for it to sync across instances. But if we write to two instances how will we ensure that only one write request succeeds? I'm sure there must be some industry standard way of doing this. But I can't seem to find anything good to read.
Asked
Active
Viewed 50 times
0
gandalf_grey
- 287
- 1
- 3
- 11
-
Does it matter if the US has an advantage if the results are always reliable? That's the kind of balance you need to consider for _concurrency_. If you google the term concurrency you'll start getting some results https://ieeexplore.ieee.org/document/916397 – Nick.Mc Nov 15 '18 at 07:34
-
@Nick.McDermaid - Thanks for sharing a link to that paper. Let me read that. So no problem with the US having an advantage when handling concurrent requests. Even if we don't consider concurrent requests, it will not be very good user experience to have clients waiting to do write half way round the world. – gandalf_grey Nov 15 '18 at 17:51