Public System Design Interview at ArchDays 2022

The main scenarios are viewing hotels and rooms, booking with payment, and cancellation. Search and detailed administration are outside the exercise. A further requirement permits ten percent overbooking. The system should be highly available, support concurrent requests, and respond to booking attempts within a few seconds. Clarifying payment allows card processing to be delegated to an external provider.

Load is estimated from market size, occupancy, average stay, and a funnel of views and reservations. This establishes orders of magnitude and the balance between reads and writes; average traffic does not describe peaks. Boundaries and APIs are then made explicit. The important step is turning vague expectations into concrete scenarios, rather than treating every preliminary estimate as precise.

The initial design associates a reservation with a particular room, which does not support the permitted excess bookings. The model is revised to reserve room types, with Inventory recording total and reserved capacity by hotel, type, and date. Reservations also need states because allocation and successful payment are separate events. Checking requirements therefore changes a diagram that has already been drawn.

The critical operation must create a reservation and increment reserved capacity consistently across the requested dates. Keeping these records in one relational database allows the updates to share a transaction. A transaction alone does not settle concurrency, however: two customers can simultaneously attempt to reserve the final capacity. The design must explicitly protect the limit and handle conflicts.

The walkthrough compares pessimistic locking, optimistic concurrency, and database constraints. Locking makes competing operations wait, while the optimistic approach requires conflict handling and retries. The author favors the latter for the assumed workload, subject to contention levels. Scaling options include partitioning by time or hotel, since hotels are relatively independent in this model.

Coordination between reservations and external payment, along with repeated client requests after a lost response, remains a separate topic. Without that work, the diagram is not a complete production design. The article explicitly acknowledges that the interview cannot cover every requirement. Candidate assessment should focus on iterative reasoning, recognizing gaps, and explaining trade-offs, rather than the appearance of having solved every possible case.