Design Hotel Reservation

Reports of this round describe a whiteboarding session that deliberately mixes high-level and low-level design, with the follow-ups arriving as separate tabs in the HackerRank portal. So expect to draw the architecture and then get pulled down into the schema, the exact query that reserves a room, and what happens when two guests race for the last one. Read the prompt for its shape before drawing anything. Search traffic dwarfs booking traffic. A guest searches many times and books at most once. So this is a read-heavy system with a small, precious write path. The write path barely moves. It just cannot be wrong.

The word that changes everything here is "providers." You are building an aggregator, closer to a travel marketplace, pulling inventory from many external systems and reselling it. That means the real source of truth for whether a room is free often sits inside someone else's API, not your database. A clean single-database booking design is only half the answer. The other half is how you stay fast and correct on top of inventory you can see but do not own.

The Wayfair angle

This prompt is reported as a mix of HLD and LLD in the same round, which tells you how it is scored. The interviewer wants the boxes-and-arrows architecture. Then they want to see you turn one of those boxes into a normalized schema, an API with real payloads, and the SQL that reserves a room without a race. That low-level pull is the Wayfair signature. Two candidates can draw the same diagram, and the one who can write the conditional UPDATE that prevents double-booking, and explain why it is safe, is the one who moves forward. Treat the data model as a first-class deliverable.