Section 2: One Sentence That Must Never Be False - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's assumptions into a contract a test could verify. We order nine capabilities by what dies without them, annotate the guest's journey with the latency each step owes (search p95 300 ms, availability check p95 150 ms, hold p95 500 ms, confirm p99 4 s), and state the one condition that makes a reservation system correct: for every (property, room_type, date), confirmed bookings plus active holds must never exceed physical inventory plus the overbooking allowance. Every non-functional number is defended, including why the booking path gets 99.99% and not a fifth nine, and why search is allowed to be thirty seconds wrong.
The interviewer uncaps the marker again. "Fine. What does it have to do?"
This is where most candidates volunteer a feature list and lose the room. A feature list is what a product manager hands you; a requirements pass is what you hand back — capabilities in priority order, targets carrying numbers, exclusions with reasons, and one invariant everything else serves. The list is the easy half.
The Functional List, in Priority Order
Priority order is not politeness. It is the order you would ship in, and the order you would sacrifice in.
| # | Capability | Why it sits here |
|---|---|---|
| 1 | Search availability by city or property, date range, occupancy | No funnel without it; highest-volume path by orders of magnitude |
| 2 | View room types with per-night rates and rate plans | We sell room types, not rooms — this is the catalogue |
| 3 | Create a hold for a date range | Nothing below this line is safe without it |
| 4 | Confirm with payment, return a confirmation number | The only step that takes money and makes a durable promise |
| 5 | Retrieve a booking by confirmation number | Guest, phone agent and front desk — three audiences, one read path |
| 6 | Modify dates or occupancy | A release plus a conditional re-acquire, not an UPDATE |
| 7 | Cancel per the rate plan's policy | Must return the computed refund — the refund is the answer |
| 8 | Front-desk check-in and check-out | Where the physical room is finally assigned (D2) |
| 9 | Inventory administration | Close-outs, allowances, rate loads — never demoed, always needed |
"You put 'create a hold' above 'cancel' and called it a requirement. Isn't a hold an implementation detail?"
No — it is a requirement, not a mechanism, because the system must be able to promise a specific room type to a guest before it has taken any money for it, and that promise must survive a crash. At requirement level that is the whole of it: a promise with a deadline, a 10-minute TTL, durable in the database (D5). Section 4 prices the window and defends its length against the obvious pushback. Redis-only holds, rejected, lose every outstanding promise on a failover, leaving you overselling or silently leaking inventory. Flip trigger: at chain scale the holds table partitions with a per-shard sweeper, still durable.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson