Hotel Distribution: Why is connecting Metasearch so hard?
Metasearch sounds great in theory till, but why do so many companies struggle to implement it.
Metasearch? What is that!
Typical OTA will keep their own records of inventory, prices and restrictions, so when a guest searches for a location they can easily serve up the data.
Meta search did away with all that cache business and said:
“Let us just live shop the supplier/hotel system every time we need some data”
This means in theory they will always have the most up do date prices as they get real time direct from the supplier
The Issue with Metasearch is volume
The idea to live shop a system for live information is great if the amount of requests were low, but the amounts are huge
Our estimate from previous experience is an average of 10,000 API requests per property per day.
So if you have 100 properties then you could estimate to get around 1 million shopping requests per day
If you have 10,000 hotels then that looks like 1 billion API calls to answer
or 700,000 requests per minute
Solutions for this?
Theres a few technical and commercial ways to deal with an issue like this:
- Retrofit your existing system to respond to meta requests.
- Build your own in-memory cache
- Partner with someone for meta (Channex!)
Retrofit for Meta
Please don’t do this.
As you see the volumes above your servers will fall over as soon as you hit 10 hotels as it was never built to scale with on demand requests.
Would be like that homemade dam you built as a child in the local stream and the stream turns into the Amazon River.
One PMS did this mistake and the meta connection flooded the server and the booking engine and pms was unusable till they switched off the meta connectivity.
If you want to retrofit then make a clone of the database server and have it separately so if it does get too much to handle it doesn't affect the rest of your system.
Build a in-memory cache system
If you have made a separate copy of the database to run the meta connectivity then you will soon hit scaling issues once you hit around 100 hotels. The costs will also start to spiral and you will question why you ever built this beast!
You are in need of a in-memory cache so you don’t hit slow db servers on each of those api calls.
The advantage of holding all data in memory is you can instantly give back the data without delay, this massively speeds up your connectivity and lowers hosting costs.
There will be some expensive architecture, dev-ops and development time involved to build a scaleable, reliable in memory system. If you have lots of resources then this is a good way to go.
Partner up!
Of course we would tell you to use our services and not use your own talents!
But bear with me here…
You can go with Channex or another provider, this method is best since you want to reduce your risk of failure on a project.
If you find that your hotels are not that into Meta Search then you haven’t wasted a lot of money.
If you find that the costs are getting too high for a 3rd party because you have many properties. You might need to build your own, you now have much better data than if you built it from the beginning.
You also have an opportunity to renegotiate or find alternative provider before you build your own solution.
Conclusion
Connecting Meta Search Channels is a tough game but can be simple by using connectivity providers that take on the pain!
