Design low-latency large-scale hotel booking system

You are asked to design the backend for a **large-scale hotel booking system** that runs behind a very high-traffic consumer app (think a TikTok-like app where a hotel goes viral and suddenly millions of users click into the same property). Users can: - Browse hotels for a city and date range. - View **near real-time availability and prices** for a specific hotel. - Place a **booking request** and receive a **confirmation or rejection**. The interviewer gives you the high-level requirements and asks you to reason carefully about **business properties first**, then derive the architecture and key trade-offs. ### Functional requirements - Search for hotels by city, date range, and basic filters. - For a given hotel and date range, show up-to-date availability (rooms left) and price. - Create a booking for a chosen hotel, room type, and date range. - Guarantee that **the same room-night is not double-booked**. - Optionally support cancellation (you can keep this high-level). ### Non-functional requirements - **High concurrency:** - Assume up to \~100k read requests/sec (availability checks) and \~10k booking attempts/sec at peak. - **Low latency:** - P99 latency for availability checks and booking confirmation should be **< 200 ms** end-to-end from the client’s perspective. - **High availability:** - The system must continue working if individual nodes or even a whole zone go down. - **Consistency characteristics:** - **Weak/eventual consistency is acceptable for displaying availability counts on the UI.** A user may occasionally see an outdated count. - **Strong correctness is required for final booking confirmation** (no double-booking). - **Message loss tolerance:** - For streaming / push-style **availability updates** to clients, it is acceptable if **some update messages are lost** (they will be refreshed soon anyway). - It is **not acceptable** to lose actual booking requests or confirmations. - **Hotspot handling:** - Some hotels may become **extremely hot** (e.g., after a viral video), causing a huge, skewed load. - The system should **avoid concentrating all traffic for one hot hotel on a single node**. - **Latency vs reliability trade-off:** - You should discuss **protocol choices** (e.g., HTTP vs WebSocket vs UDP or similar) and how they impact latency and reliability. ### Specific discussion points the interviewer cares about 1. **Latency vs reliability:** - When and why might you choose a low-overhead protocol such as **UDP or WebSocket-style persistent connections** instead of plain HTTP for certain flows? - Which parts of the system can tolerate message loss, and which cannot? 2. **Preventing double bookings for the same hotel/room:** - Under high concurrency, how do you ensure two users cannot both successfully book the **last available room-night**? - Discuss techniques such as **rate limiting, request coalescing/merging, throttling, and concurrency control** (locks, atomic counters, queues, etc.). 3. **Sharding / horizontal scaling for hot hotels:** - How would you horizontally partition the load for a very hot hotel? - Compare strategies like **sharding by room** (e.g., room ID or room type) versus **bucketizing by user** (e.g., hashing on user ID) and discuss pros/cons. Assume you are free to pick any technologies (e.g., relational vs NoSQL databases, caches like Redis, message queues like Kafka, etc.). **Task:** Design the system at a high level: - Identify the major components/services. - Propose a data model for hotels, rooms, inventory, and bookings. - Describe the end-to-end flows for **availability lookup** and **booking confirmation**. - Explain how your design achieves: - Low latency with acceptable reliability trade-offs. - No double-booking despite high concurrency. - Good handling of **hot hotels** via sharding/partitioning. - Explicitly call out the key trade-offs and why you made those choices.