Why booking tests availability and concurrency in LLD - Why This Architecture

Problem Statement

When multiple users try to book the same test slot at the same time, the system can allow double bookings or fail to update availability correctly. This causes confusion, lost revenue, and poor user experience because the system does not handle concurrent requests properly.

Solution

The system manages test slot availability by controlling access to booking data so that only one booking can succeed for a slot at a time. It uses concurrency control techniques like locking or atomic operations to ensure that availability updates happen safely without conflicts, preventing double bookings.

Architecture

User 1

(Request) ─┼──────▶

→Service ├──────▶

↓

User 2

(Request) ─┼───────────┘

↓

Lock/Mutex

Lock/Mutex

This diagram shows two users sending booking requests to the booking service. The service uses a lock or mutex to control access to the database test slot records, ensuring only one booking updates availability at a time.

Trade-offs

✓ Pros

→

Prevents double booking by serializing access to test slot availability.

→

Maintains data consistency and accurate availability status.

→

Improves user trust by avoiding booking conflicts.

✗ Cons

→

Locking can reduce system throughput under very high concurrency.

→

Complexity increases with distributed locks or multi-datacenter setups.

→

Potential for deadlocks or increased latency if not implemented carefully.

Use when your system handles multiple simultaneous booking requests for the same test slots, especially if you expect more than 100 concurrent users.

If your booking volume is very low (under 10 concurrent requests) or test slots are unique per user, the overhead of concurrency control may not be justified.

Real World Examples

Uber

Uber prevents multiple drivers from accepting the same ride request by locking the ride assignment, ensuring only one driver can book the ride.

Airbnb

Airbnb manages concurrent booking requests for the same property dates by locking availability calendars to avoid double bookings.

Amazon

Amazon controls inventory availability during flash sales by locking stock counts to prevent overselling.

Code Example

The before code reads and updates availability without any protection, so two requests can read the same available count and both book, causing double booking. The after code uses a lock to ensure only one thread updates availability at a time, preventing conflicts.

LLD

### Before: No concurrency control, leads to double booking
class BookingService:
    def book_slot(self, slot_id):
        slot = database.get_slot(slot_id)
        if slot.available > 0:
            slot.available -= 1
            database.save_slot(slot)
            return True
        return False

### After: Using a lock to prevent concurrent updates
import threading
lock = threading.Lock()

class BookingService:
    def book_slot(self, slot_id):
        with lock:
            slot = database.get_slot(slot_id)
            if slot.available > 0:
                slot.available -= 1
                database.save_slot(slot)
                return True
            return False

Alternatives

Optimistic Concurrency Control

Instead of locking, it checks for conflicts after the fact and retries if conflicts occur.

Use when: Use when conflicts are rare and you want to maximize throughput without locking overhead.

Eventual Consistency with Conflict Resolution

Allows temporary inconsistencies and resolves conflicts asynchronously later.

Use when: Use when immediate consistency is not critical and system can tolerate short-term conflicts.

Summary

Concurrent booking requests can cause double bookings without proper control.

Using locks or atomic operations ensures only one booking updates availability at a time.

This approach improves data consistency and user experience but may reduce throughput under high load.