Chapter 7: Hotel Reservation System Design

The design scope is established for a large hotel chain, encompassing 5,000 hotels and one million rooms, incorporating key features such as customer cancellations and supporting a 10% overbooking allowance in anticipation of those cancellations. Initial back-of-the-envelope calculations estimate a relatively low average reservation transaction per second (TPS) of 3, although high concurrency must be supported during peak booking events. The high-level architecture adopts a microservice architecture, featuring components like the Hotel Service, Rate Service, Reservation Service, Payment Service, and Hotel Management Service, managed via a Public API Gateway and Internal APIs. A relational database is chosen due to the workflow being more read-heavy than write-intensive and, crucially, because it provides ACID guarantees (atomicity, consistency, isolation, durability) necessary to prevent issues such as double reservations or double charges within a transaction system. A schema refinement is necessary to reflect that users reserve a room type rather than a specific physical room, leading to the creation of the room_type_inventory table to track available and reserved counts per date and room type. To manage concurrency challenges, especially preventing a user from accidentally creating two reservations, the system utilizes Idempotent APIs by enforcing a unique constraint on the reservation_id. Addressing more complex race conditions where multiple users book the last available room concurrently, the chapter evaluates locking mechanisms, ultimately finding pessimistic locking non-scalable due to potential deadlocks, and favoring optimistic locking (using version numbers) or database constraints because the Query Per Second (QPS) for reservations is typically not high. For scalability enhancements, strategies include database sharding based on the hotel_id and implementing an Inventory Cache (like Redis) for fast read operations, while maintaining the primary database as the ultimate source of truth. Finally, the text discusses complexities surrounding data consistency among services in a microservice environment, advocating for a pragmatic hybrid design approach where inventory and reservation data share a single relational database to leverage ACID properties for critical transaction consistency, rather than relying on advanced, complex patterns like Saga or Two-phase commit (2PC).