Booking conflict resolution in LLD - Scalability & System Analysis

Scalability Analysis - Booking conflict resolution

Growth Table: Booking Conflict Resolution

Users	Booking Requests/Second	Conflict Rate	Database Load	Locking/Queueing	Latency
100 users	~10	Low	Single DB instance handles well	Minimal locking	Low latency
10,000 users	~1,000	Moderate	DB under moderate load, some locks	Lock contention visible	Latency increases slightly
1,000,000 users	~100,000	High	Single DB overloaded	High lock contention, queueing delays	High latency, timeouts possible
100,000,000 users	~10,000,000	Very high	DB cluster needed, sharding required	Distributed locking or conflict resolution needed	Latency critical, fallback needed

First Bottleneck

The database is the first bottleneck because booking conflict resolution requires checking and updating availability atomically. As user requests grow, the DB faces high contention and locking delays, causing slow responses and possible failures.

Scaling Solutions

• Optimistic Locking: Use version numbers or timestamps to detect conflicts and retry without heavy locks.
• Pessimistic Locking: Lock resources during booking to prevent conflicts but can reduce concurrency.
• Queueing Requests: Serialize booking requests per resource to avoid conflicts.
• Horizontal Scaling: Add more application servers behind load balancers to handle more requests.
• Database Sharding: Partition booking data by resource or region to reduce contention.
• Caching Availability: Use cache to reduce DB reads, but ensure cache consistency.
• Conflict Resolution Service: Use a dedicated service or distributed lock manager (e.g., Redis Redlock) to coordinate bookings.
• Eventual Consistency: For less critical bookings, allow temporary conflicts and resolve asynchronously.

Back-of-Envelope Cost Analysis

• At 1,000 booking requests/sec, DB needs to handle ~1,000 QPS with atomic checks.
• Each booking record ~1 KB, 1M bookings/day -> ~1 GB storage/day.
• Network bandwidth depends on request size; assume 1 KB/request -> ~1 MB/s at 1,000 QPS.
• Locking and retries increase CPU usage on DB and app servers.
• Scaling DB horizontally and adding caching reduces cost per request.

Interview Tip

Start by explaining the booking flow and where conflicts happen. Identify the database as the bottleneck due to atomicity needs. Discuss trade-offs between optimistic and pessimistic locking. Propose scaling by sharding and caching. Mention fallback strategies like queueing or eventual consistency. Keep answers structured: problem, bottleneck, solution, trade-offs.

Self-Check Question

Your database handles 1000 QPS for booking requests. Traffic grows 10x to 10,000 QPS. What do you do first and why?

Answer: The first step is to reduce database contention by implementing optimistic locking and adding read replicas for scaling reads. Also, consider sharding booking data to distribute load. This prevents the DB from becoming a bottleneck due to locking delays.

Key Result

Booking conflict resolution first breaks at the database due to locking and contention. Scaling requires locking strategies, sharding, caching, and horizontal scaling of app and DB layers.

Practice

1. What is the primary goal of booking conflict resolution in a system?

easy

A. To ignore booking times and accept all requests

B. To allow multiple bookings at the same time for efficiency

C. To delete all previous bookings automatically

D. To prevent overlapping reservations for the same resource

Solution

1. Step 1: Understand booking conflict concept

   Booking conflict resolution ensures no two bookings overlap for the same resource.

2. Step 2: Identify the goal of conflict resolution

   The goal is to prevent double-booking by checking time overlaps and rejecting or adjusting conflicting bookings.

3. Final Answer:

   To prevent overlapping reservations for the same resource -> Option D

4. Quick Check:

   Conflict resolution = prevent overlaps [OK]

Hint: Conflict resolution means no double bookings allowed [OK]

Common Mistakes:

• Thinking multiple bookings at same time are allowed
• Assuming conflict resolution deletes bookings
• Ignoring time overlaps in bookings

2. Which of the following code snippets correctly checks if two time intervals (start1, end1) and (start2, end2) overlap?

easy

A. if start1 < end2 and start2 < end1: overlap

B. if start1 > end2 or start2 > end1: overlap

C. if end1 <= start2 or end2 <= start1: no overlap

D. if start1 == end2 or start2 == end1: overlap

Solution

1. Step 1: Understand time interval overlap condition

   Two intervals overlap if one starts before the other ends and vice versa.

2. Step 2: Match condition to code

   Condition start1 < end2 and start2 < end1 correctly detects overlap.

3. Final Answer:

   if start1 < end2 and start2 < end1: overlap -> Option A

4. Quick Check:

   Overlap check = start1 < end2 and start2 < end1 [OK]

Hint: Overlap if intervals cross each other in time [OK]

Common Mistakes:

• Using <= instead of < causing false negatives
• Confusing no overlap with overlap conditions
• Checking equality as overlap incorrectly

3. Given existing bookings: [(10, 12), (14, 16), (18, 20)], what will be the result of checking a new booking (12, 14) for conflict using the overlap condition start1 < end2 and start2 < end1?

medium

A. Conflict with (10, 12)

B. Conflict with (14, 16)

C. No conflict

D. Conflict with all existing bookings

Solution

1. Step 1: Check overlap with each existing booking

   Check (12,14) against (10,12): 12 < 12 is false, no overlap. Against (14,16): 12 < 16 true, 14 < 14 false, no overlap. Against (18,20): no overlap.

2. Step 2: Determine conflict result

   No overlaps found with any existing booking intervals.

3. Final Answer:

   No conflict -> Option C

4. Quick Check:

   New booking fits between existing without overlap [OK]

Hint: Check each existing booking for overlap carefully [OK]

Common Mistakes:

• Assuming touching intervals overlap
• Ignoring strict less than condition
• Confusing start and end times

4. Identify the bug in this booking conflict check code snippet:

def is_conflict(new_start, new_end, existing_bookings):
    for start, end in existing_bookings:
        if new_start <= end and new_end >= start:
            return True
    return False

medium

A. The condition incorrectly uses <= and >= causing false conflicts

B. The condition allows bookings that end exactly when another starts

C. The function does not return anything

D. The loop does not iterate over bookings

Solution

1. Step 1: Analyze the overlap condition

   Condition new_start <= end and new_end >= start includes cases where bookings just touch at edges, causing false conflicts.

2. Step 2: Correct condition for strict overlap

   Use new_start < end and new_end > start to detect true overlaps only.

3. Final Answer:

   The condition incorrectly uses <= and >= causing false conflicts -> Option A

4. Quick Check:

   Use strict inequalities for overlap [OK]

Hint: Use < and >, not <= or >= for overlap checks [OK]

Common Mistakes:

• Using inclusive operators causing false positives
• Forgetting to return a boolean
• Not iterating over all bookings

5. You are designing a booking system for meeting rooms. To handle conflict resolution at scale, which approach is best to ensure no overlapping bookings and high performance?

hard

A. Use a centralized lock on the entire booking database for each new booking

B. Check for conflicts by querying only relevant time slots and use optimistic concurrency control

C. Allow all bookings and resolve conflicts manually later

D. Store bookings without timestamps and rely on user honesty

Solution

1. Step 1: Understand scalability and conflict resolution needs

   Centralized locking (Use a centralized lock on the entire booking database for each new booking) causes bottlenecks; manual or no checks (Options C, D) cause errors.

2. Step 2: Choose efficient conflict detection method

   Querying only relevant time slots reduces load; optimistic concurrency control handles race conditions efficiently.

3. Final Answer:

   Check for conflicts by querying only relevant time slots and use optimistic concurrency control -> Option B

4. Quick Check:

   Efficient conflict check + concurrency control = scalable solution [OK]

Hint: Query relevant slots + optimistic control for scalable conflict resolution [OK]

Common Mistakes:

• Using global locks causing slowdowns
• Ignoring concurrency issues
• Not filtering bookings by time before checking