← Back to companies
[ OK ] Loaded —
[ INFO ]
$ cd
$ ls -lt
01
02
03
04
05
$ ls -lt
01
02
03
04
05
user@intervues:~/$
Build a hotel booking platform that enables travelers to discover accommodations, reserve rooms, and manage their stays. The system must handle real-time inventory tracking across thousands of properties, dynamic pricing that varies by date and demand, and concurrent booking attempts during high-traffic periods like holiday weekends.
Users search by destination and travel dates, browse room options with accurate pricing, complete reservations with payment, and manage bookings through modifications or cancellations. The technical challenge lies in maintaining data integrity when inventory is scarce -- preventing double-bookings while serving search results with sub-second latency. You need to model nightly room availability at scale, compute total stay costs from per-night rates and fees, and orchestrate multi-step booking flows spanning payment processing, inventory updates, and confirmation delivery.
Based on real interview experiences, these are the areas interviewers probe most deeply:
Interviewers want to see you model availability per night, per room type -- not as a simple boolean at the hotel level. A multi-night stay spanning dates with partial availability must be handled correctly to prevent overselling some nights while others are available.
Hints to consider:
When multiple users attempt to book the last available room simultaneously, your system must prevent overselling. Interviewers expect specific transactional mechanisms and an understanding of performance trade-offs between locking strategies.
Hints to consider:
Search traffic vastly exceeds booking volume, and complex filter queries (location, dates, amenities, price range) would overwhelm the transactional database. Interviewers look for clear separation between OLTP and search workloads.
Hints to consider:
Hotels apply layered pricing rules: base rates vary by season and day of week, occupancy modifiers add surcharges, taxes differ by jurisdiction, and promotions apply discounts. Interviewers want structured thinking about where pricing logic lives and how it remains performant.
Hints to consider:
A booking is not atomic -- it involves inventory hold, payment authorization, reservation creation, confirmation delivery, and potentially rollback if payment fails. Interviewers probe how you maintain consistency across these steps.
Hints to consider:
Confirm whether you are designing for a single hotel chain or a marketplace aggregating thousands of properties. Clarify if real-time pricing updates from hotels are needed or if overnight batch updates suffice. Ask about expected search and booking volumes, geographic distribution, and peak traffic patterns. Verify functional boundaries: are you responsible for payment processing or calling an external gateway? Do cancellations refund automatically?
Sketch a service-oriented architecture. A Search Service backed by Elasticsearch handles discovery queries with filters, returning hotel metadata and availability flags. A Booking Service owns the transactional workflow, interacting with PostgreSQL to check precise inventory and create reservations. A Pricing Service computes total costs from base rates, taxes, and fees. A Payment Service wraps interactions with payment gateways. An Inventory Service updates nightly availability counts and publishes events to refresh the search index asynchronously via Kafka. Place Redis for caching search results and holding soft-locks during checkout.
Walk through a reservation. The user selects dates and a room type. The Booking Service starts a database transaction and queries the inventory table for all dates in the range: 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 with PENDING status and a generated confirmation code. It then calls the Payment Service with an idempotency key. On payment success, the reservation transitions to CONFIRMED and the transaction commits. If payment fails or times out, the transaction rolls back, returning inventory to the pool. A background job scans for expired PENDING reservations every 30 seconds and releases them. Discuss how FOR UPDATE locks prevent concurrent transactions from seeing stale availability, and how the (hotel_id, room_type_id, date) index ensures the range scan completes in milliseconds.
Cover search scaling: read replicas for search-related queries that tolerate slight lag, with all inventory writes routed to the primary. Discuss caching strategy: cache event metadata aggressively but never cache available inventory counts directly. For analytics, stream booking events to a data warehouse via Kafka for reporting dashboards. Address monitoring: track reservation timeout rates, payment failure rates, and checkout abandonment funnels. Design for multi-region: place read replicas near users globally, but route payments and inventory writes to a single authoritative region for consistency. Explain fraud detection by integrating third-party scoring services. Touch on disaster recovery: daily backups, ability to switch payment providers, and documented runbooks for peak-traffic incidents.