May 3, 2017 at 10:43 am
Good day!
I've got a massive headache trying to come up with a solution for a very particular scenario, I figure I could get some suggestions/wisdom around here.
I'm building a booking system that its fairly simple, just a few tables and not a lot of forms (WinForms) the trouble is that its gonna be used on two locations. One is in the UK (main one) and the other one on a remote island far away from the UK, beyond the bandwidth limitation on the island there's the requirement for both to keep the data synchronized.
This operation leaves SQL Server Replication out of the possibilities because they need to be notified about changes (Inserts and Updates), so for example location A creates a record (booking) that data then is sent to location B but its displayed to the user before being included on his side.
Even after that's sorted there's the discussion about how can data be sent from one server to the other, would that need to stay on a middle ground server or can it be sent directly somehow?
Many questions, any suggestion?
May 3, 2017 at 11:58 am
Can you use a single database, put it in azure and add logic around the add some logic around accepting a change
May 3, 2017 at 12:43 pm
A hotel reservation system is certainly an application where you want to have each user accessing a central database. If it's important to have an operational fail-over mode, just in case one or both locations lose internet connectivity, then perhaps have them using a central cloud hosted database by default and then a low latency replication process can synchronize a local database at each office. In the event that internet connectivity is lost, it would only then fail over to using the local database, but only in read-only mode, just so they can lookup customer account information or whatever until connectivity is restored.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 3, 2017 at 7:02 pm
You need not just place a booking, you need also to make sure the booking can be actually placed.
Because it's possible that 30 seconds before the booking placed on location A the same room (or whatever you're booking) was booked by a client on location B.
Therefore, every booking must stay "requested" until it's "confirmed" (or "rejected").
And while it's "requested" the system sends a request from Location A to Location B, where the request gets validated, possible conflicts are resolved according to the business rules, and a confirmation message carrying corresponding status of the booking is sent back to Location A.
User gets notified about the outcome of the request and can act accordingly.
You may not wish to have "Primary Database", you may run 2 instances independently from each other.
In this case booking requests on both locations should be treated equally: both locations send requests over, and fix bookings only after corresponding confirmations received from another system.
To me, that would be a preferred option, because business logic might require to accept the earlier placed booking, no matter where was it made from, so "master" instance cannot confirm a booking without checking if there was another one for the same room done on "secondary" location earlier, but delayed in transition.
_____________
Code for TallyGenerator
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply