Context - I'm building a flight booking system (online travel agent) that will partner many airlines to sell their seats. 

I've designed my architecture to work like this: 

1. When a user searches for a flight route, a request goes to look up a cache
2. If the cache has available flight inventory, return it to the user
3. If it does not, create a job in a queue
4. Sometime later, a queue consumer will pick up the job and hit the airline's API / website to retrieve flight inventory. Once retrieved, they will be placed into the cache.
5. The code in #1 polls again, retrieve the inventories in the cache, and display the search results to the user.

Benefits of this setup so far:

* the queue / asynchronous fetching approach provides a buffer to prevent hitting airline systems too much
* the cache provides very fast response

Problems encountered:

* Very high memory usage on the cache due to the huge variety of flight routes available
* For routes that are not searched often, users will need to wait a while as the system is polling to get the search content
* If an airline gone down, then there won't be any inventory data available, causing the user to see nothing + loss of sales

How will you improve the design?

———— EDIT ————

More context:

* In the travel industry, every airline has a Look-To-Book ratio given to distribution partners. For example if you hit their API / website too often but not book, then you will be penalized.
* In addition, every airline also stipulates maximum number of clients able to connect from a partner.
* This distribution site works with hundreds of airlines and serve millions of requests a day.
* Latency to the airlines easily take from 2s - 15s. They are not too tech savvy.
* There are additional middlemen partners too like GDS (example: Amadeus) to pull flight routes from.