OK, so please tell me if this is the worst idea ever, or if it might have some merit. Here it goes:
I have a customer who uses a legacy application that stores data in an Omnis database file (*.DF1). This application manages reservations and bookings for campgrounds, and is locally hosted on a server that runs at my customer's site. The customer is able to take reservations online via a third party bookings engine, but it's not quite fully automated - the site manager has to upload an availability list to the booking site, and then even once a booking is made, the manager has to call and confirm the reservation (most likely because due to sync issues it's possible to double-book).
Only around 5% of reservations are currently made online; the rest are by phone. We're looking to tilt that drastically in the other direction as we ramp up online marketing efforts and target new customers, so we need a way to support easy and accurate online booking in a way that can scale. The bookings engine doesn't have an API, and of course neither does this legacy application (both are actually made by the same parent company).
My initial plan is to build a set of APIs that can connect to this local database file and expose web services to allow retrieval and creation/updating of bookings. This way, the site manager can still use the app for creating reservations as per usual, but we now have control of online bookings by being able to sync with the source database. I plan to solve load issues by using an intermediary database hosted on AWS to act as a surrogate system of record. Reservations would be written into the surrogate database, then inserted into the source database.
Basically the setup would look something like this:
Website --> Bookings Web Service --> Surrogate Bookings DB (AWS) --> Java client on site-managed server --> Source DB
I do realize that there could still be sync issues here in that the site manager could be creating a booking, but I could potentially solve that by sending an email or alert when an online booking is made, so that if they are on the phone with a customer they have the latest view into what is being booked online.
Is having a separate API that can write into a database that another application can also write into a recipe for disaster? The other solution is to keep my surrogate bookings database totally separate, but then I have the issue of how we make absolutely sure that nothing gets double-booked in the main system because they would be disconnected.
Would appreciate any insight as to how people get around these kinds of issues when legacy applications meet modern requirements.