Booking.com / Airbnb — High-Level Design

Login, search, book a room if it is free, pay, and see past bookings. Scale is 100M MAU and ~1 million hotels. Bookings need both high availability and consistency — the same room must not sell twice. Entities are User, Hotel, Room, and Booking. APIs cover /user/login, /hotels/search, /hotels/:id, POST /booking, and GET /bookings/:id.

Day 0 is one server and one database — simple, not scalable, a single point of failure. Day N puts an API + load balancer in front of User, Search, Booking, Booking Info, and Review, each with its own store. Hotel DB holds hotel, rooms, price (date-ranged), and availability (AVL / Booked / Maintenance).

GET /hotels/search needs name + location + date, which is proximity search. Options are Elasticsearch, a quad tree, PostGIS, or geohash. Search reads Elasticsearch; Hotel DB stays the source of truth; CDC denormalizes hotel rows into the index so the search cluster never hits the transactional store.

Elasticsearch finds hotels that match the query; Redis holds availability so results can be filtered to rooms actually free on those dates — without a join on Hotel DB at read time. Hotel images go through a CDN so listing pages stay fast.

Gateway handles auth, rate limits, and round-robin. Booking takes a Redis lock, talks to Room Availability, then Payment (gateway + Payment DB). On success it publishes to Kafka: consumers write Booking DB, update availability, and fire the notification service. CDC still keeps Elasticsearch in sync with Hotel DB.

POST /booking {hotel_id, roomId, capacity, date} → lock in Redis so two users cannot grab the last room → pay via the payment gateway → Kafka. Consumers notify the guest, persist the booking, and mark the room booked. Booking Info reads Booking DB for past stays. The lock is what makes the last room consistent; Kafka keeps the write path short.