Reservation and hold system in LLD - System Design Guide

Problem Statement

When multiple users try to book the same limited resource simultaneously, conflicts arise causing double bookings or lost reservations. Without a mechanism to temporarily lock or hold resources, users may experience frustration due to inconsistent availability and failed transactions.

Solution

This pattern introduces a temporary hold on resources when a user initiates a reservation, preventing others from booking the same resource during the hold period. If the user completes the booking within the hold time, the reservation is confirmed; otherwise, the hold expires and the resource becomes available again.

Architecture

User A

(Client)

→& Hold System

↓

User B

(Client)

→& Release

This diagram shows two users interacting with the reservation and hold system which communicates with the resource database. The system places temporary holds on resources and releases them upon expiry if not confirmed.

Trade-offs

✓ Pros

→

Prevents double booking by locking resources during the hold period.

→

Improves user experience by providing immediate feedback on availability.

→

Allows automatic release of resources if users abandon the booking process.

✗ Cons

→

Requires careful management of hold expiration to avoid resource starvation.

→

Adds complexity to the system with timers and state tracking for holds.

→

Potentially reduces resource availability temporarily due to holds.

Use when resources are limited and contention is high, such as ticket booking or hotel reservations, especially when user decision time is significant (e.g., more than a few seconds).

Avoid when resource availability is abundant or when booking decisions are instantaneous, as the overhead of managing holds outweighs benefits.

Real World Examples

Airbnb

Airbnb uses reservation holds to temporarily lock a property while a user completes payment, preventing others from booking the same property simultaneously.

Ticketmaster

Ticketmaster places holds on seats during the checkout process to prevent double booking and ensure fair access to limited event tickets.

Uber

Uber holds a driver for a rider during the booking process to avoid multiple riders being assigned the same driver.

Code Example

The before code allows direct booking without any temporary lock, risking double booking. The after code introduces a hold system that locks a resource for a user temporarily, preventing others from booking it until the hold expires or is confirmed.

LLD

### Before: No hold system, direct booking
class ReservationSystem:
    def __init__(self):
        self.booked_resources = set()

    def book(self, resource_id):
        if resource_id in self.booked_resources:
            return False  # Already booked
        self.booked_resources.add(resource_id)
        return True


### After: Reservation with hold system
import time
import threading

class ReservationSystem:
    def __init__(self, hold_time_seconds=30):
        self.booked_resources = set()
        self.holds = {}  # resource_id -> (user_id, expiry_time)
        self.hold_time = hold_time_seconds
        self.lock = threading.Lock()

    def place_hold(self, resource_id, user_id):
        with self.lock:
            now = time.time()
            # Clean expired holds
            expired = [r for r, (_, exp) in self.holds.items() if exp <= now]
            for r in expired:
                del self.holds[r]

            if resource_id in self.booked_resources or resource_id in self.holds:
                return False  # Not available
            expiry = now + self.hold_time
            self.holds[resource_id] = (user_id, expiry)
            return True

    def confirm_booking(self, resource_id, user_id):
        with self.lock:
            hold = self.holds.get(resource_id)
            if hold and hold[0] == user_id:
                del self.holds[resource_id]
                self.booked_resources.add(resource_id)
                return True
            return False

    def release_hold(self, resource_id, user_id):
        with self.lock:
            hold = self.holds.get(resource_id)
            if hold and hold[0] == user_id:
                del self.holds[resource_id]
                return True
            return False

Alternatives

Optimistic Locking

Instead of holding resources, it allows concurrent access and checks for conflicts at commit time.

Use when: Choose when conflicts are rare and the cost of retries is acceptable.

Pessimistic Locking

Locks resources immediately and exclusively until the transaction completes, blocking others.

Use when: Choose when conflicts are frequent and consistency is critical.

Summary

Reservation and hold systems prevent double booking by temporarily locking resources during user decision time.

They improve user experience by providing immediate feedback and automatic release of unconfirmed holds.

Managing hold expiration and concurrency is critical to avoid resource starvation and ensure fairness.

Practice

1. What is the primary purpose of a hold in a reservation and hold system?

easy

A. To delete all reservations from the system

B. To permanently reserve a resource without expiration

C. To cancel a confirmed reservation immediately

D. To temporarily block a resource before final booking

Solution

1. Step 1: Understand the role of a hold

   A hold temporarily blocks a resource to prevent others from booking it while the user decides.

2. Step 2: Differentiate hold from reservation

   A reservation is permanent until canceled, while a hold expires if not confirmed.

3. Final Answer:

   To temporarily block a resource before final booking -> Option D

4. Quick Check:

   Hold = Temporary block [OK]

Hint: Holds are temporary blocks, not permanent reservations [OK]

Common Mistakes:

• Confusing hold with permanent reservation
• Thinking holds never expire
• Assuming holds cancel reservations

2. Which data structure is best suited to track holds with expiration times efficiently?

easy

A. Simple array without ordering

B. Linked list without timestamps

C. Hash map with timestamps and a priority queue for expirations

D. Stack data structure

Solution

1. Step 1: Identify requirements for hold tracking

   We need fast lookup by hold ID and efficient expiration handling.

2. Step 2: Choose data structures

   A hash map allows quick hold lookup; a priority queue orders holds by expiration for timely removal.

3. Final Answer:

   Hash map with timestamps and a priority queue for expirations -> Option C

4. Quick Check:

   Hash map + priority queue = efficient hold tracking [OK]

Hint: Use hash map for lookup and priority queue for expirations [OK]

Common Mistakes:

• Using unordered arrays causing slow expiration checks
• Choosing stack which is LIFO, not suitable for expirations
• Ignoring timestamps in data structure

3. Consider this pseudo-code for confirming a hold:

if hold.exists(hold_id) and not hold.is_expired(hold_id):
    reservation.create(hold.resource)
    hold.remove(hold_id)
    return "Confirmed"
else:
    return "Failed"

What will be the output if the hold has expired?

medium

A. "Failed"

B. "Confirmed"

C. Error due to missing hold

D. "Confirmed" but resource is double booked

Solution

1. Step 1: Check hold existence and expiration

   The code confirms only if hold exists and is not expired.

2. Step 2: Analyze expired hold case

   If hold is expired, condition fails and returns "Failed" without creating reservation.

3. Final Answer:

   "Failed" -> Option A

4. Quick Check:

   Expired hold = "Failed" confirmation [OK]

Hint: Expired holds cause confirmation to fail [OK]

Common Mistakes:

• Assuming expired holds confirm successfully
• Expecting errors instead of failure message
• Ignoring hold expiration check

4. A developer wrote this code to release expired holds:

for hold in holds:
    if hold.expiration_time < current_time:
        holds.remove(hold)

What is the main issue with this code?

medium

A. Holds should not be removed, only marked expired

B. Modifying a list while iterating causes skipped elements or errors

C. Expiration time comparison is incorrect

D. Loop should use while instead of for

Solution

1. Step 1: Understand iteration and modification

   Removing items from a list while iterating over it causes skipping or runtime errors.

2. Step 2: Identify correct approach

   Use a separate list to collect expired holds or iterate over a copy to safely remove.

3. Final Answer:

   Modifying a list while iterating causes skipped elements or errors -> Option B

4. Quick Check:

   Remove during iteration = skipped elements [OK]

Hint: Never remove items from list while looping over it [OK]

Common Mistakes:

• Ignoring iteration modification side effects
• Assuming expiration comparison is wrong
• Thinking loop type causes the issue

5. You need to design a scalable reservation and hold system for a popular event with thousands of simultaneous users. Which approach best ensures no double booking and timely hold expiration?

hard

A. Use distributed locks on resources, store holds with TTL in a distributed cache, and confirm with atomic transactions

B. Store all holds in a single database table without expiration, confirm by updating status

C. Allow multiple holds per resource and resolve conflicts manually later

D. Use client-side timers to expire holds and update server asynchronously

Solution

1. Step 1: Prevent double booking with distributed locks

   Distributed locks ensure only one user can hold a resource at a time across servers.

2. Step 2: Use TTL in distributed cache for hold expiration

   TTL automatically expires holds after timeout, preventing indefinite blocking.

3. Step 3: Confirm holds atomically

   Atomic transactions guarantee reservation creation without race conditions.

4. Final Answer:

   Use distributed locks on resources, store holds with TTL in a distributed cache, and confirm with atomic transactions -> Option A

5. Quick Check:

   Distributed locks + TTL + atomic confirm = scalable, safe system [OK]

Hint: Combine distributed locks, TTL cache, and atomic confirm for scale [OK]

Common Mistakes:

• Ignoring concurrency causing double booking
• Relying on client-side expiration only
• Not using atomic operations for confirmation