Keep channels online, even though underlying systems are offline?

Question

We have six very old systems where the newest one is built 1995. All these systems have batch jobs running from midnight to 6 AM every night, and these systems are offline. On top of these six systems there is an API from which different channels access data from the six systems. Every channel is naturally also offline between these hours, since they depend on the API which in term depend on the six mainframe systems (see schematic drawing below).

Now, we have new business rules saying that the channels need to be online 24 hours 7 days a week. Our interpretation of that is that customers need to be able to access their data, even though the underlying systems are offline due to batch processing jobs.

So, my question is: How do we take advantage of the API, synchronize and store the data to be used when the underlying systems are offline? Do we use a caching mechanism, or do we build a database application which synchronizes data on a schedule?

More information based on feedback in comments

1. Can you clarify whether the systems are usually online, i.e. handle requests for the API?

   • Systems are online between 6 o'clock in the morning and midnight. Channels are online 24/7 but without access to systems from midnight to 6 o'clock.

2. Do the API operations execute business rules or do they just request data from the underlying systems?

   • API only requests and receives data. The drawing is overly simplified, but the business logic lives in the underlying systems 1-6.

3. Are there specific reasons (like hardware cost, risks of changing code) why the systems cannot be duplicated so that one system can handle batch operations while the other answers API requests?

   • I'm not sure, I have to dig deeper to answer. Cost is always a factor, but not to the extent that it would stop a business need like this one.

4. Would it be possible to queue API requests and execute them after the systems are back online?

   • Not really. It's an insurance system, and customers only want to access their data as they where when systems where last online.

5. Typically a B2B channel would support submissions of things like orders. The other two channels could also support submissions. Are you quite sure this is limited to data retrieval?

   • At the moment, there are limitations to the old systems in this case. We want to show insurances, terms, documents but not make any changes during offline hours. But in the time frame of 5-6 years, the old systems will be replaced by a newer system and by then support submissions. This is not ideal, but an compromise between business needs and technical constraints.

Answer 1

I don't think it's possible without addressing the underlying problem of the batch jobs taking the system offline.

The solution would be as you say to copy the whole datasource prior to the batch jobs starting, and point the api at that until the systems come back online.

But if you need to take the system offline to run these batch jobs, I think copying the whole database, without any downtime, is going to be problematic.

Similarly the caching approach effectively requires you to build up and keep a copy of the entire database in a cache all the time. Unless the queries are limited to a much smaller set of data, its not going to be very effective.

Answer 2

The distinction you drew between a database application and caching is probably not helpful. Whether you use a database or not to store the data doesn't matter much. And though in a sense what you are doing is caching, its not really quite typically what one would call caching (since its not driven by calls from the requester side and since what you need to store is a complete copy of the available data).

But what you need to do is clear. Save TWO copies of the full set of available data, one called MOST RECENT, and one called NEXT MOST RECENT. Every time you have access to the new data (as soon as you have access to it) -

• delete "NEXT MOST RECENT"
• start copying the data to a new storage area
• when done copying, rename the existing MOST RECENT DATA to "NEXT TO MOST RECENT" and rename your temporary holding data (that you just copied) to "MOST RECENT"

And always serve up data from the public facing APIs from the database table "MOST RECENT".

Use a database, or filesystem storage as you wish, based on what's easiest for your existing API implementation and the form of the data you currently extract from the mainframes. Nothing about this rotation plan requires introducing a database.