How does Booking.com guarantee consistency of reservations on scale?

It’s fundamentally a distributed problem because it involves a hotel.

If the worst case scenario the hotel could be totally screwed up (IT error, bankruptcy, nature disaster, …) and you might not be able to stay there. Booking.com has to have something in the contract they serve you under that says in some cases they will put you up in another hotel, offer a refund or something but maybe in others they don’t.

Even in the short term though it is the real reservation at the hotel that matters, not the state of their system, so there has to be some kind of concurrency control for the system as a whole.

As far as I know they don’t have guarantees. They simply make good on refunding if there’s a downstream issue (e.g. hotel is overbooked).

If I had to make a wild guess, on top of a lot of ways of handling this technically, there's probably a set of business-policies they follow in the event of some problem like a room being double-booked, or a lodging otherwise becoming unavailable after the reservation is made.

> In the (hopefully rare) event of a problem, they probably try and keep people happy through a standard playbook of things like refunds, giving future coupons or discounts, and trying and arranging alternative lodging.

> Even if their databases could somehow guarantee to be perfectly consistent and no random booking problems occur, they still need those standard policies in place to deal with random hotel problems like flooding or other problems.

Booking.com doesn't handle the reservations themselves, just facilitates you interacting with the hotel's reservation system. Booking.com probably plugs into the Central Reservation System for the hotel at some point whether it be at the chain level, the hotel level, or through something like the GDS (Global Distribution System). When booking.com starts a transaction it first asks for availability from the hotel, presents that availability to the user, then the user chooses if they want to accept any of the availability.

Once the user chooses the reservation it's blocked off directly in the Central Reservation System at the hotel so it can't be double booked. If the rooms fill up between the availability being presented and the user deciding the CRS won't accept the reservation then booking.com then has to handle that use case with the user.

So Booking.com itself probably doesn't really have any "floating" reservations where the user is told it's booked and the hotel doesn't know about it. It's all pretty much done in real-time.

Business background: The unit of the hotel industry is the "roomnight". Globally, let's assume an average of 100 hotels per city and 10,000 cities and 100 rooms per hotel. While any of those numbers could be argued to be off by an order of magnitude they aren't so far from the upper bound reality as a central booking platform. So you are only booking a maximum of 100M roomnights per day, or 4.1M roomnights per hour, or 70K roomnights per minute, or 1200 roomnights per second. The SQLite FAQ states that it can do 50,000 or more inserts per second on an average computer. https://www.sqlite.org/faq.html#q19 Since 50K/1.2K = 41, we could say roughly 41x100M roominghts per day could be handled on such an average system. So 4.1 billion roomights per day, at which point we are booking over half of the entire global population of humans, every night. Hand-waving generalities aside, I think we can conclude there is no technical problem. Largely, namespacing guarantees uniqueness without the need for a shared ledger to facilitate greater parallelism.

Business-wise, if you are worried about contention, the locking is achieved within hotel reservation systems at two levels. One level is the channel, and another level is the hotel itself. The hotel itself holds the ultimate record of note with respect to forward room allocations, re-allocation powers, deferment and cancellation powers, etc. They are the arbiter of truth. However, because hassling staff or systems at the hotel are not always optimal distribution solutions, large channels such as major booking sites will often be hard or soft-allocated groups of rooms in bulk. They are then able to provide their own confident sub-assignment of these rooms before communicating the ultimate guest details to the hotel. Conceptually, this functions similarly to exchange-based trades in crypto, broker-based book allocations in the conventional financial services world, and so on.

The ultimate client-facing business process is generally handled with a soft booking at agreed rates, and then a hard confirmation of the receipt and agreement to booking by the hotel receiving the notification of such from the reservation channel. Different hotels offer different interfaces for this, but not so long ago a huge amount was still done by fax. It wouldn't surprise me if a great deal are still done manually by humans using email. Larger operations use APIs, but all fall back to each hotel's reservations department who have the power to issue contracts, change rates, and override agreements. A web-booking consumer would typically pay and receive a confirmation of payment immediately, and for hotels not offering real time reservation confirmation APIs receive a deferred confirmation via email.

FWIW IIRC booking.com was one of the higher-vis perl holdouts globally, at least 10 years ago.

Source: Around 2007-2009 I developed from scratch a hotel reservation system operating in six human languages which grew to over 3,000 partner hotels. This is not so big these days but at the time was the same size as multiple NASDAQ listed operations.

> specially with a massive number of concurrent users

I think that's where you're wrong... first of all, the number of hotel booking transactions is nowhere near the number of social media interactions, for example. It's not massive at all -- it's something any modern database server can handle easily, and using replication for reads as required.

And secondly, even if it were massive, it's not massive per-property which is the only thing that matters. Database sharding in this case is incredibly straightforward, compared to many other types of websites. And in both cases, just use normal transactions.

Now, in reality, as other commenters have attested, it's actually a communications process with each property that has nothing to do with databases at all, and overbooking can absolutely happen when both Booking.hom and Hotels.com book the same last room before the hotel has confirmed one. And then it gets sorted out manually, by the hotel, because the hotel is aware of it.

They don’t ensure that technically. I have had countless times things were double booked. They ensure it humanly by refunds and finding alternatives.

I have run into consistency issues on booking where it'd show you a room and then say it's not available when you try to book. Go back, refresh, there's a room, book -> error again.

But to answer your question, it's probably more about hotels advertising truthful number of rooms than booking's system, and I believe booking makes sure hotels don't overbook by penalizing them.

They don’t ensure that technically. I have had countless times things were double booked. They ensure it humanly by refunds and finding alternatives.

Their tech model is very simple (I know quite a lot of people there), but it works well.

Unfortunately last time I used booking.com to book a flight I didn't get my passport registered on the ticket, and it's quite unclear if the fault is of the airline booking or the aforementioned one :/

Hijacking this thread to ask which data structure is best for storing hotel reservations?

BASE.

Here's a secret: most of the world runs on BASE. Even banks.

Chapter 7 of Alex Xu’s Volume 2 has a nice description of most of the problems. Below, a post that has a good level of details.

https://devinz1993.medium.com/book-notes-system-design-inter...

Extracted from the post:

Chapter 7. Hotel Reservation System

Functional requirements: - View hotels and rooms. - Reserve a hotel room. - Add/delete/update a hotel room. - Support overbooking.

Non-functional requirements: - Support high concurrency. - Moderate latency (a few seconds for reservation).

Recommendations: - Choose a relational database for the read-heavy workload and ACID properties. - Include an idempotency key in the API for making reservations to avoid double booking. - Use the microservice architecture and use remote procedure calls for inter-service communication. - Keep a pre-populated room type inventory (for 2 years ahead) to support reservations by room type (instead of by room id).

Concurrency control: - Pessimistic locking is prone to deadlocks and tends to have bad performance. - Optimistic locking is usually faster but performance dramatically drops when contention is heavy.

Scaling: - Shard the database by hotel since most queries need to filter by it. - Cache inventory information (aggregates) in Redis to reduce database load and improve read performance.

Tip: - Use the same service to manage reservations and the inventory to avoid data consistency issues that require 2PC or Saga.