Katkat
Back

Design a Venue Rental and Booking System (HLD)

SalesforceSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design a high-level architecture for a venue rental marketplace, focusing on inventory availability modeling, concurrency control to prevent double-booking, and resilient schema and API design under read-heavy traffic.

Scenario

Design a venue rental and booking marketplace (similar to Airbnb for event spaces or Peerspace) that connects venue hosts (offering conference halls, party spaces, and meeting rooms) with guests seeking to book spaces for specific dates or hourly blocks.

Requirements

Functional Requirements

  1. Listing Management: Hosts can list venues with details (capacity, amenities, hourly/daily base rate, cancellation policies) and define standard working hours or blacked-out periods.
  2. Search and Discovery: Guests can search and filter venues by location, capacity, date/time window, and amenities.
  3. Reservation & Double-Booking Prevention: Guests can select an available time window, place a temporary hold (e.g., 10 minutes) during checkout, and confirm the booking upon successful payment. Overlapping bookings for the same venue must be strictly prevented.
  4. Booking Lifecycle: Support basic booking states: HELD, CONFIRMED, CANCELLED, and EXPIRED.

Non-Functional Requirements

  1. Consistency: Strong consistency is required for the booking flow to guarantee zero double-bookings. Eventual consistency is acceptable for search listings.
  2. High Availability: High availability for browsing and search, even during peak booking windows.
  3. Latency: Venue search response time under 200 ms (p95); booking creation under 500 ms (p95).

Scale Assumptions

  • Listings: 5 million active venues globally.
  • Traffic: 30 million Daily Active Users (DAU); 50 million searches per day (average ~600 QPS, peak 3,000 QPS).
  • Bookings: 500,000 reservations attempted per day (~6 bookings/sec average, peak 100 bookings/sec).
  • Read-to-Write Ratio: High read-heavy workload (~100:1).

Key Focus Areas

  1. API Design: Define the primary endpoints for searching venues, creating temporary holds, and confirming bookings.
  2. Data Model: Schema design for venues, availability/calendar representation (e.g., slot-based vs. interval/range-based), and bookings.
  3. High-Level Architecture: Overall system diagram including search indexing, transactional booking service, cache tier, and message queues.
  4. Concurrency & Race Conditions: Mechanisms for handling simultaneous booking attempts for the same venue and time slot (e.g., DB locks, Redis-based distributed locks, state machine with TTL).

Hints

Hint 1

Differentiate between discrete slot-based modeling (e.g., 30-minute chunks) and arbitrary interval-based modeling (start and end timestamps), evaluating trade-offs in search complexity and database row locking.

Hint 2

Decouple the read-heavy search infrastructure from the booking engine using an inverted index (e.g., Elasticsearch) populated via change data capture (CDC) from the primary database.

Hint 3

Use a two-phase reservation approach where a temporary slot hold is acquired via a distributed lock or database conditional update with a short TTL, followed by final confirmation upon payment completion.

Follow-up questions

  • How would you handle custom pricing models such as tiered hourly rates, weekend premiums, or dynamic cleaning fees across timezone boundaries?
  • If the business introduces a 'request to book' flow requiring host approval within 24 hours, how does that affect slot holding and availability indexing?
  • How would you shard the database to balance high write contention on popular venues while maintaining efficient date-range queries?