Booking conflict resolution in LLD - System Design Guide

Problem Statement

When multiple users try to book the same resource (like a hotel room or a meeting slot) at the same time, conflicts occur. Without proper handling, double bookings happen, causing customer frustration and operational chaos.

Solution

The system checks availability before confirming a booking and locks the resource during the booking process to prevent others from booking it simultaneously. If a conflict is detected, the system rejects or queues the request, ensuring only one booking succeeds for the same time slot.

Architecture

User 1 Client

→Booking Server

↓

User 2 Client

─────────┘

This diagram shows two users attempting to book the same resource. The booking server checks availability and locks the resource to prevent conflicts.

Trade-offs

✓ Pros

→

Prevents double bookings by locking resources during booking.

→

Ensures data consistency and user trust in the booking system.

→

Can handle concurrent booking requests safely.

✗ Cons

→

Locking can reduce system throughput under very high load.

→

Complexity increases with distributed systems needing distributed locks.

→

Potential for deadlocks or resource starvation if not managed carefully.

Use when booking resources that cannot be double-booked and when concurrent booking requests exceed 100 per second.

Avoid if booking conflicts are rare (under 10 per hour) or if eventual consistency is acceptable for the application.

Real World Examples

Airbnb

Prevents double booking of rental properties by locking availability during the booking process.

Uber

Resolves conflicts when multiple riders request the same driver simultaneously by locking driver availability.

Booking.com

Ensures hotel room availability is locked during booking to avoid overbooking.

Code Example

The before code allows double bookings because it does not lock the resource during booking. The after code uses locks per resource and time slot to ensure only one booking can succeed at a time, preventing conflicts.

LLD

### Before: No conflict resolution
class BookingSystem:
    def __init__(self):
        self.bookings = {}

    def book(self, resource_id, time_slot):
        if (resource_id, time_slot) in self.bookings:
            return False  # Double booking possible but not prevented
        self.bookings[(resource_id, time_slot)] = True
        return True


### After: With locking to prevent conflicts
import threading

class BookingSystem:
    def __init__(self):
        self.bookings = {}
        self.locks = {}
        self.global_lock = threading.Lock()

    def book(self, resource_id, time_slot):
        key = (resource_id, time_slot)
        with self.global_lock:
            if key not in self.locks:
                self.locks[key] = threading.Lock()
        lock = self.locks[key]

        with lock:
            if key in self.bookings:
                return False  # Conflict detected
            self.bookings[key] = True
            return True

Alternatives

Optimistic concurrency control

Allows multiple bookings to proceed but checks for conflicts before final commit, rolling back if conflicts exist.

Use when: Choose when conflicts are rare and system prefers higher throughput over immediate locking.

Eventual consistency with compensation

Accepts bookings immediately and resolves conflicts later by compensating or notifying users.

Use when: Choose when immediate consistency is not critical and user experience can tolerate delays.

Summary

Booking conflict resolution prevents double bookings by locking resources during the booking process.

It ensures data consistency and user trust by handling concurrent requests safely.

Choosing the right conflict resolution strategy depends on system load and tolerance for conflicts.