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

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 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.