How the interviewer opens it
“Design a hotel booking service like Booking.com. Guests should be able to search for stays by date, reserve rooms, and complete bookings without double-booking.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Inventory model and authority
- Stay semantics
- Catalog size
- Traffic and read:write mix
- Latency
- Consistency versus availability
- Holds and payments
- Pricing
- Durability and deployment
- Scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Search hotels and room types by location, dates, and guest count
- Quote a stay and temporarily hold the requested rooms across every night
- Complete payment and confirm a booking without overselling
- Retrieve the current hold or booking status
Usually out of scope
- Hotel onboarding and revenue-management algorithms
- Physical room assignment at check-in
- Synchronizing inventory with other booking sites
- Building a payment processor
- Loyalty programs, packages, and multi-hotel checkout
What interviewers probe
- Atomic inventory across a date range
- A stay consumes capacity on several nights, and overlapping stays contend on only some of those nights. Reserving nights independently can leave partial reservations or oversell the busiest night.
- Date-aware search over changing inventory
- A hotel matching the location is not enough: the same room type must satisfy the requested quantity on every night. Search must evaluate this cheaply without turning stale results into booking guarantees.
- Payment completion versus hold expiration
- The database and payment provider cannot commit atomically. A payment can succeed after the room has been released, and retries or delayed callbacks can otherwise duplicate charges, bookings, or inventory releases.
Common mistakes
- Treating availability as a hotel-level count instead of a room-type count for each stay date.
- Checking each night independently without an all-or-nothing reservation transaction.
- Using search or cached availability as the source of truth for booking.
- Ignoring the race between payment success and hold expiration.
- Assuming a payment timeout means no charge occurred, or omitting idempotency for client retries.
- Using UTC timestamps or inclusive checkout dates in ways that consume the wrong hotel nights.
The bar by level
- Senior (L5/E5)
- Drives the multi-night invariant, lock ordering, and all-or-nothing allocation. Designs date-aware search without loading the booking database, and gives a concrete hold/payment state machine covering timeout, expiration, duplicate requests, and late-success refunds.
- Staff (L6+/E6+)
- Makes inventory ownership and guarantee boundaries explicit, especially for external channels and regional failover. Identifies hot-property contention despite modest aggregate writes, chooses the simplest storage topology that fits, and reasons through recovery, projection repair, and payment reconciliation without weakening booking correctness.