The search functionality is the first product feature that the customers will see. If the experience is not good, an immediate impact will be seen on the business. As described, the top key requirements of search are performance and personalization. Another requirement is to ensure that we don't incur high costs from the sellers, considering the look-to-book ratio. Let's look at how we can engineer the same.

In general, for the search, the inputs are going to be places and dates. Specifically for flights, the search inputs will be as follows:

• The onward date. The return date would be optional (only for return flights).
• The source and destination places (airports).

Whereas, for hotels the search parameters would include the following:

• The check-in and check-out date
• The city/country/hotel name where the room is desired

Generally, travel websites take the number of passengers as well. But since this does not affect the architecture drastically, it is ignored for the purpose of the solution engineering of this case study.

For both flights and hotels, the search response consists of the following:

• A Static listing: This is the elements of the catalog that match the query. The catalog is essentially a dictionary of items available. For flights, this is a cache of flight details (flight names, aircraft types, services offered, and so on) between any two airports. Here, the actual source of truth are the external sellers. Similarly, for hotels, the catalog contains content on the room types, images, ratings, and so on.
• A dynamic part: This is the prices for each element in the listing. Here, the prices vary based on the context (who's searching, when, whether there are discounts, and so on). You generally want the newest price available, so we need to cache prices less aggressively than the static listings. However, we also want to optimize look-to-book penalties, so our cache TTLs here have to be smart, as discussed in the following section.