Katkat
Back

Design a Rental Search and Booking Platform from Startup to Scale

HeadwaySoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a short-term rental search and booking system, balancing eventual consistency in search discovery with strict consistency during reservations and checkout.

Scenario

You are tasked with designing the core search and booking engine for a short-term property rental platform. The platform must support two primary user journeys: finding available accommodations via faceted geographic search, and reserving a property without the risk of double-booking.

Your design should outline both the initial MVP architecture (appropriate for early startup stage) and how the system evolves to support high-throughput, global scale.

Requirements

Functional Requirements

  • Search & Discovery: Users can search for properties by location, date range (check-in to check-out), guest count, and price filters.
  • Authoritative Availability: When viewing a property detail page, users must see the exact, real-time availability calendar.
  • Reservation Flow: Users can initiate a booking, placing a temporary hold on the property (e.g., 10–15 minutes) while completing payment.
  • Payment & Confirmation: Complete the reservation upon successful payment or release the hold if the session expires or payment fails.
  • Host Management: Hosts can manage calendar blocks and pricing.

Non-Functional Requirements

  • Zero Double-Bookings: Strict consistency is required for the final booking step.
  • Search Latency: Search results should return within 200ms at p95.
  • Availability vs. Consistency Trade-off: Search results may tolerate slight staleness (e.g., a newly booked property might appear in search for a few seconds), but initiating a reservation must strictly validate true availability.
  • Fault Tolerance: Automatic recovery and inventory release if the checkout service, user, or payment gateway crashes mid-transaction.

Scale Estimates

  • Startup Stage: 5,000 active listings, 20,000 DAU, negligible concurrent contention on any single property.
  • Scale Stage: 1,000,000 active listings, 10,000,000 DAU, 5,000 search queries per second (QPS), and high contention on popular listings during peak booking windows.

What to Cover

  1. High-Level Architecture: Core services, data flow, and components for both startup and scaled phases.
  2. Data Modeling: Schema design for listings, daily availability/slots, reservations, and holds.
  3. Concurrency Control: Mechanisms to prevent double-booking (e.g., DB row locking, distributed locks, conditional writes).
  4. Eventual Consistency in Search: How the search index (e.g., Elasticsearch/OpenSearch) is updated from the transactional database without blocking writes.

Hints

Hint 1

Separate read-heavy search indexing from the authoritative transactional booking flow using an event-driven architecture.

Hint 2

Model availability at the daily/nightly level rather than simple start/end dates so you can use atomic operations or unique constraints across date spans.

Hint 3

Use a short-lived 'held' status with an idempotent expiration mechanism (such as Redis TTLs, delay queues, or scheduled sweeps) to automatically unlock abandoned checkouts.

Follow-up questions

  • How do you handle the race condition where a payment gateway confirms a charge just as the 15-minute hold expires and another user claims the dates?
  • How does your search indexing strategy handle bulk updates, such as when a host closes their calendar for an entire year?
  • If you need to support flexible date searches (e.g., 'stay for any 3 days in July'), how does that change your search query architecture and caching strategy?