← Back to companies
[ OK ] Loaded —
[ INFO ]
$ cd
$ ls -lt
01
02
03
04
05
$ ls -lt
01
02
03
04
05
user@intervues:~/$
Design a hotel booking platform similar to Booking.com or Expedia where travelers search for hotels by destination and travel dates, browse room options with per-night pricing, make reservations with payment, and manage their bookings through modifications or cancellations. The system must maintain accurate room availability across thousands of properties and prevent double-bookings when multiple users attempt to reserve the last room simultaneously.
The core engineering challenges are modeling nightly inventory at scale (a multi-night stay must have availability on every individual night), preventing double-booking under concurrent reservation attempts, separating read-heavy search traffic from write-heavy booking transactions, computing accurate pricing from complex rate structures, and orchestrating multi-step booking workflows involving inventory holds, payment processing, and confirmation delivery. You will need to reason about data modeling, concurrency control, search infrastructure, and saga-based workflows.
Based on real interview experiences at Carta, Rippling, Meta, Zoom, JPMorgan Chase, and Oracle, these are the areas interviewers probe most deeply:
The heart of the system is how you track room availability at per-night granularity. A hotel with 50 rooms of three types across 365 days creates tens of thousands of inventory cells per property. Interviewers want to see you model this correctly so multi-night availability checks are efficient.
Hints to consider:
inventory table with columns for hotel_id, room_type_id, date, and available_count; each row represents one room type on one nightWhen two users try to book the last room for the same dates simultaneously, exactly one must succeed. Interviewers expect explicit transactional strategies that prevent overselling without destroying throughput.
Hints to consider:
SELECT available_count FROM inventory WHERE hotel_id = ? AND room_type_id = ? AND date BETWEEN ? AND ? FOR UPDATE; if all nights have availability, decrement each and insert the reservation in the same transactionSearch traffic vastly exceeds booking volume. Users expect fast, filterable results with complex geo and amenity queries. Running these against the transactional database would be ruinous.
Hints to consider:
A reservation spans inventory hold, payment authorization, reservation creation, and confirmation delivery. Each step can fail independently, and the system must handle retries and rollbacks cleanly.
Hints to consider:
Hotels apply complex rate structures: base rates vary by date, occupancy surcharges apply, taxes differ by jurisdiction, and promotional discounts overlay. Interviewers want structured thinking about where this logic lives.
Hints to consider:
pricing table keyed by (hotel_id, room_type_id, date_range); use date-range lookups to fetch rates for the stayConfirm whether the system covers a single hotel chain or a marketplace aggregating thousands of properties. Ask if real-time pricing feeds from hotels are needed or if overnight batch updates suffice. Clarify expected search and booking volumes, geographic distribution, and whether payment is processed or delegated to an external gateway. Verify cancellation and modification policies.
Sketch a service-oriented design. Search service: backed by Elasticsearch, handles filtered queries and returns hotel metadata with availability flags and minimum prices. Booking service: owns the transactional workflow, interacting with PostgreSQL for inventory and reservation management. Pricing service: computes total costs from base rates, taxes, and fees. Payment service: wraps interactions with the payment gateway. Inventory service: manages nightly availability counts and publishes events to refresh the search index asynchronously. Place Redis in front of hot paths for caching search results and managing soft-holds during checkout. Use Kafka to decouple inventory updates from search reindexing, maintaining eventual consistency without blocking bookings.
Walk through the core booking flow. A user selects dates and a room type. The booking service starts a PostgreSQL transaction: it queries SELECT available_count FROM inventory WHERE hotel_id = ? AND room_type_id = ? AND date BETWEEN ? AND ? FOR UPDATE. If every night has at least one room, it decrements available_count for each date and inserts a reservation row with a PENDING status and a generated confirmation code. The service then calls the payment service with an idempotency key. On payment success, it updates the reservation to CONFIRMED and commits the transaction. If payment fails or times out, it rolls back, returning inventory to the pool. Discuss how FOR UPDATE row locks prevent concurrent transactions from overselling, and how the composite index on (hotel_id, room_type_id, date) keeps the range scan fast.
Cover search scalability: Elasticsearch indexes updated via Kafka consumers with eventual consistency; popular queries cached in Redis. Discuss pricing: a dedicated service applying rate tables, occupancy modifiers, and tax rules. Address booking management: modification creates a new reservation and cancels the old one atomically; cancellation triggers refund via the payment service. Mention monitoring: track booking success rate, lock wait times, search p95 latency, cache hit rates, and Kafka consumer lag. Discuss scaling: partition the inventory table by date, use read replicas for search-related queries, and scale the booking service horizontally behind a load balancer.