We got acquainted with the travel industry pitfalls, when we accepted a challenge to do a prototype of apartment aggregator. This was not only the beginning of building a site for millions users, but also a start for gaining business knowledge and development tricks to make travel site successful.
This was a prototype for http://roomlr.com, a Netherland's startup aimed to be meta search engine on short start rentals. Now, the site features over 1500000 apartments worldwide. It took near two years to have current version. You are welcome to try it while planning your next holiday.
The most useful lesson we learnt developing Roomlr backend was the importance of detailed agreement with partners. No doubt, solid partnership will allow you to provide your clients high quality service, but only if you gain guarantees in the agreement. The priorities include obtaining topical and credible data and general standards of work.
Air tickets industry is another ocean which waters we tried out and even made some successful rides to the underwater. Thus, working with such a giant as http://ifly.ua, we learned how to maintain stability, provide high quality health monitoring and achieve scalability. As we had to collaborate with several partners, we had to learn how to be flexible enough.
Short example. Say you have 5 partners which can give you flights list for certain dates and directions. You have to work with each of them in parallel to give user first results fast. Also you have to merge flights in one feed to prevent duplicates in result list. You have to be very cautious with the process running on each flight. For example, conversion of currency can take only 0.005 seconds, but on a list of 1000 results, it will take 5 seconds, which is a lot for the user to wait for. It requires lot's of optimisations in bottlenecks.
Working in travel area, one is usually tightly connected with money and prices. Price for ticket, rent etc. Moreover, pricing model is usually quite complicated in this area. For example, a price for a certain apartment often depends on numerous factors:
1) duration of stay;
2) amount of guests and their age, in particular different price for children, youth and babies;
3) period of stay, which can depend on general day type, public holidays, for example if one arrives on Friday it will be more costly that to come on Monday.
There could be even limitation that allow to start your journey only on Monday, because that is a way how apartment owner is used to work. One must take into account all that moments in a search form to deliver correct and precise results for users.
Freshness of the information is not less essential. For apartments it implies calendar info, as it's important to know when an owner updated it last time. Although a small delay is acceptable for the apartments booking site, it's not tolerated on air tickets platforms. Usually every 15 minutes it's necessary to refresh results and query partners again. Typically, there is one more query before placing order to ensure that flight is not booked. What is more, a booking order just pre-reserve a ticket and it's necessary to confirm when user sent payment details.
Advanced search. As it was mentioned above, there are lots of options that affect final price. For example, it's an amount of users to reserve the item and their types (adult, youth, children, baby). And of course calendar and location. Your search engine should allow to handle all those queries. There also could be advanced ordering and ranking, you'll have different sources of the data, and you could show results from providers that give you the best quality of items.
Big amount of data. Since results depend on dates, many variants are expected. It requires complex structure to store all of them. For example, you have 1000 apartments in your database. Each of them will have 10 - 30 pictures and availability info. Imagine we store calendar for each record for next 18 month for each day. In total for only 1000 apartments we’ll have about 20 000 images and 540 000 records for calendar info.
Another example is processing the items from partners. For example, we have a search for flights from Amsterdam to Berlin and partners provide us 1000 results for specific dates. We will merge them and it will become 100 items, but at the very moment of search you have 1000. And assume that all the records are given with different currencies and we want to convert it into user's currency. Say one conversion takes 0.005 seconds, as a result to process all the items will take 5 seconds! And it's only currency conversion. It's extremely important to find bottlenecks in data processing and find workarounds.
In travel area you have to work with partners to provide high quality service. On the programming level we usually work using API (application program interface). The matter is that they will always change it: some will become deprecated, some will have bugs, some will interrupt at some point. Thus, it’s necessary to build monitoring process for partner APIs and have procedures to handle all such cases. It often involves much communications with them, so we need to be prepared.
Typically we serve users from different parts of the world and show them results from different parts of the world. We have to store all the descriptions in multiple languages. Sometimes automatic translate can be allowed.
In addition, we need to show adequate prices in all the currencies supported by the site. And the more are supported, the better.
When one has lot's of data, complex search and ranking, it becomes heavy to process it. It could be that 5 simultaneous search load a server to 100% CPU. Of course we have to optimise it constantly.What is more, it's required to know how we handle more customers prime time of your site, e.g. a season of advertisement campaign. It should be well planned while building the architecture of the platform. There should be a way to add more servers within a day and handle all the paying customers.
You can fail, your partners could fail but you must serve users who pay you. First of all you must prepare clear explanation for your users when your site is not able to handle requests. It should be a page that you can show in case something bad happens. Next level is to monitor all the critical parts: 1) all site pages are working 2) searches are working 3) your partner's working 4) load of your servers
As you parters change things often, we should be ready to keep up with them.
On travel site, one obviously should allow searching target location (it could be country, city, village or even street). To handle it properly one should have a database of all existing cities, countries, regions, islands, etc in your database and be able to search there properly, using autocomplete. Typically, there are two solutions:
use autocomplete from Google: it's easy to integrate, no resources taken to store all cities in the world required, but you can't really dig into customising geo autocomplete like you want.
have internal database of locations that you store and query.
Drop us a line on firstname.lastname@example.org and we schedule a meeting to discuss it.