Design a **venue / facility rental system** that lets organizers — schools, clubs, and event organizers — discover and rent out physical venues. Venues are booked through different **rental packages** (for example, an "Hourly Conference Room" package, a "Full-Day Hall" package, or a "Weekend Sports Field" package), each with its own pricing and time granularity. This is a **high-level design** question. The interviewer's focus is explicit: identify the core **entities**, design a sound **database schema**, define the **APIs**, and model the **relationships** between system components. You are expected to reason about how availability is represented, how bookings avoid double-booking, and how the read (search) and write (book) paths are served. ### Constraints & Assumptions - Assume on the order of **tens of thousands of venues** and **millions of registered users/organizers**. - Booking volume is **read-heavy**: searching/browsing availability vastly outnumbers actual bookings. - A venue may offer **multiple rental packages**; a package defines what time unit can be booked (hour, half-day, day, weekend) and the price. - A booking reserves a specific venue (via a package) for a specific time window and must **never** be allowed to overlap an existing confirmed booking for that same venue/space. - Payment is required to confirm a booking, but you may treat the payment provider as an external service. - Bookings can be **canceled** (subject to a policy) and may need approval by the venue owner in some configurations. ### Clarifying Questions to Ask - Who are the actors — renters (organizers), venue owners/managers, and platform admins — and what can each do? - Does a single venue have one bookable space, or multiple sub-spaces/rooms that can be booked independently and concurrently? - Is booking instant-confirm (pay and you're booked) or request/approval based (owner must accept)? - What time granularities must we support (hourly, daily, multi-day), and are there blackout dates or recurring availability rules? - What are the cancellation/refund rules, and do we need to model them in the system? - Do we need search by location/capacity/amenities, and how important is geo-search? ### Part 1 — Core entities, relationships, and database schema Identify the core entities and design a relational schema for them. Capture venues, the spaces within them, rental packages, availability, bookings, users/owners, and payments, and make the relationships (one-to-many, many-to-many) explicit. Pay particular attention to how you represent **availability and a booked time window** so that overlap can be checked. ```hint Entity decomposition Separate `Venue` (the place, with location/amenities) from the **bookable unit** and from the **RentalPackage** (pricing + time unit). A `Booking` references a venue/space + a package + a `[start, end)` time range + a status. Owners and renters are both `User`s with roles. ``` ```hint Modeling the booked window Store each booking as a half-open interval `[start_time, end_time)` on a specific bookable space. Two bookings overlap iff `a.start < b.end AND b.start < a.end`. This predicate (plus an exclusion/uniqueness guarantee at the DB level) is what prevents double-booking — design the schema so you can enforce it. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2 — API design Define the key APIs for the main flows: an owner listing a venue and its packages, a renter searching for available venues, viewing a venue's availability, creating/confirming a booking, and canceling a booking. Specify representative request/response shapes and status semantics. ```hint Shape the booking call around idempotency The "create booking" endpoint mutates shared availability and triggers payment — design it to be idempotent (accept a client-supplied key) and to move through explicit states (PENDING → CONFIRMED / FAILED / CANCELED) rather than booking in one irreversible step. ``` #### Clarifying Questions for this Part - Should search return only fully-available venues for the requested window, or also partially-available ones with alternative slots? - Is booking confirmation synchronous with payment, or do we confirm asynchronously on a payment webhook? #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 3 — Availability, booking integrity, and scaling Explain how the system serves the read-heavy search/availability path at scale while guaranteeing the write path never double-books a venue. Address concurrency (two renters trying to book the same slot at once), and how the read and write paths are scaled differently. ```hint Concurrency The naive "check availability then insert" has a race. Resolve it with a single atomic guard: a database exclusion/unique constraint on (space, time-range) so the second overlapping insert fails, or a short-lived hold/lock per slot — then reconcile with payment via a PENDING hold + TTL. ``` ```hint Read vs. write split Searching availability is dominated by reads; serve it from read replicas and/or a search index (e.g., for geo + amenity filters) and cache hot results, while routing the comparatively rare, consistency-critical booking writes to the primary. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - A venue has several independently bookable rooms. How does your schema and overlap check change, and how do you keep search fast across all of them? - How would you support **recurring** bookings (e.g., a club rents a hall every Tuesday for 10 weeks) and partial cancellation of one occurrence? - A renter starts checkout but their payment takes 90 seconds. How do you hold the slot, what's the TTL, and what happens to a competing renter during that window? - How would you add location-based search ("venues within 5 km that seat 200, available next Saturday afternoon") and keep it consistent with the booking source of truth?