For someone not familiar with the pitfalls of the online travel business it may be surprising that one of the major problems consists in the delivery of accurate prices in real time. As rate calculation takes time this information is usually cached. However, conventional databases struggle with the sheer amount of data.
First published: 28/03/2021 | Last update: 01/04/2021
The rules for price calculation in the hospitality industry can be tremendously complex which is why price calculation at request time and data transformation is error prone and a performance killer.
Finally the use of artificial intelligence to maximize revenue has lead to prices that are not based anymore on deterministic systems and cannot be calculated from a bunch of input data.
In order to provide reliable response times especially on sites with high volumes of traffic, the rate and availability data (also called ARI for availability, rate and inventory) must be kept in a place from where it can be retrieved within miliseconds. Not only that, but this information must constantly be kept up-to-date.
In the past it was not uncommon that developers from outside the travel industry would try to use different types of databases to cache calculated rates just to find out that these systems will struggle with the sheer amount of data. The solution was throwing tons of bare metal onto the problem which might solve some of the performance problems by creating others, let alone increasing the cost.
At the beginning of the past decade Peakwork with their Player/Hub technology came up with a viable solution to provide new search possibilities and excellent response times. Their approach was to move away from centralized rate caching and use a de-centralized network instead.
While I think that Peakwork technology is probably still the best solution in terms of performance in the market, there are some use cases where I think that a simpler and slimmer solution may be a better fit. This is the case where systems for contract and inventory management do a good job selecting accommodations according to search criteria such as location, airports, features/characteristics, ratings, etc., but struggle with providing rate and availability information in real time.
This is where OpenRateCache comes into play, a highly specialized cache with the capacity to store billions of rates and availabilities and to retrieve this information within fractions of a second.
Why the open source release?
I had been working on a system which not only would cache rates and availability but would also offer interfaces to apply mark-ups and currrency exchange rates at request time; open searches with facets (GlobalTypes), location, airports, etc.; de-duping and code matching and finally enrichment with non-bookable content. There was quite a bit of interest just before Covid-19 but most customers would want to have only the actual caching part.
As Covid-19 hit the world of travel orders and projects were cancelled so in the end I would have to give up my status as freelance and look for a job. I used the time to improve my job profile and also decided to learn a new programming language: Go.
I thought implementing the ratecache core in go would be a nice first project so this is what I did. At the same time I realized that difficulties finding a new job grow exponentially as you get older. Which is why I decided to publish the go-code for the rate cache under a Berkley license and call it OpenRateCache.