Why booking tests availability and concurrency in LLD - Scalability Evidence

Scalability Analysis - Why booking tests availability and concurrency

Growth Table: Booking Tests Availability and Concurrency

Users	Requests per Second	Concurrent Bookings	Database Load	System Changes
100 users	~10-50 RPS	~5-10 concurrent	Low, single DB instance	Simple locking, basic availability checks
10,000 users	~1,000 RPS	~200-300 concurrent	Moderate, DB nearing capacity	Introduce caching, connection pooling, read replicas
1,000,000 users	~50,000 RPS	~5,000 concurrent	High, DB bottleneck likely	Sharding, distributed locking, queueing for concurrency control
100,000,000 users	~5,000,000 RPS	~500,000 concurrent	Very high, multiple DB clusters	Global distribution, advanced concurrency control, event sourcing

First Bottleneck

The database is the first bottleneck because booking tests require checking and updating availability atomically to avoid double bookings. As concurrency grows, locking and transaction conflicts increase, causing delays and failures.

Scaling Solutions

• Horizontal scaling: Add more application servers behind load balancers to handle more concurrent requests.
• Database read replicas: Offload read queries to replicas to reduce load on the primary DB.
• Caching: Cache availability data to reduce DB hits, with short TTL to keep data fresh.
• Sharding: Partition booking data by region or test center to reduce contention.
• Distributed locking or optimistic concurrency: Use Redis or Zookeeper to manage locks or version checks to prevent double bookings.
• Queueing: Serialize booking requests in a queue to control concurrency and avoid conflicts.
• Event sourcing: Use event logs to track bookings and rebuild state, improving consistency at scale.

Back-of-Envelope Cost Analysis

• At 10,000 users: ~1,000 RPS -> DB must handle ~1,000 writes/reads per second.
• Storage: Each booking record ~1 KB, 1M bookings = ~1 GB storage.
• Bandwidth: Assuming 1 KB per request/response, 1,000 RPS = ~1 MB/s network usage.
• Concurrency control adds latency; expect 50-100 ms per booking transaction at scale.

Interview Tip

Start by identifying the critical resource (database) and why concurrency causes issues. Discuss how availability checks must be atomic to prevent double bookings. Then explain scaling steps: caching, read replicas, sharding, and concurrency control mechanisms. Always justify why each solution fits the bottleneck.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas and implement caching to reduce load on the primary database before considering sharding or more complex solutions.

Key Result

Booking test availability systems first hit database bottlenecks due to concurrency and atomic availability checks; scaling requires caching, read replicas, sharding, and distributed concurrency control.

Practice

1. Why is it important to handle concurrency when booking test slots in a system?

easy

A. To allow unlimited bookings for the same slot

B. To slow down the booking process intentionally

C. To prevent multiple users from booking the same slot at the same time

D. To avoid showing available slots to users

Solution

1. Step 1: Understand concurrency in booking

   Concurrency means multiple users try to book the same slot simultaneously.

2. Step 2: Identify the problem caused by concurrency

   If concurrency is not handled, multiple users can book the same slot, causing double bookings.

3. Final Answer:

   To prevent multiple users from booking the same slot at the same time -> Option C

4. Quick Check:

   Concurrency handling = prevent double bookings [OK]

Hint: Concurrency means multiple users booking simultaneously [OK]

Common Mistakes:

• Thinking concurrency allows unlimited bookings
• Ignoring the need to prevent double bookings
• Assuming concurrency slows down the system intentionally

2. Which of the following is a correct way to ensure availability checks during booking in a system?

easy

A. Check slot availability after booking confirmation

B. Lock the slot before confirming the booking

C. Allow booking without checking availability

D. Ignore concurrency and rely on user honesty

Solution

1. Step 1: Understand locking in booking systems

   Locking a slot means reserving it temporarily to prevent others from booking it simultaneously.

2. Step 2: Identify when to check availability

   Availability must be checked and locked before confirming booking to avoid conflicts.

3. Final Answer:

   Lock the slot before confirming the booking -> Option B

4. Quick Check:

   Lock before confirm = correct availability check [OK]

Hint: Lock slot before booking to avoid conflicts [OK]

Common Mistakes:

• Checking availability after booking causes errors
• Ignoring availability checks leads to double bookings
• Relying on user honesty is not a system design

3. Consider this simplified booking flow code snippet:

def book_slot(slot_id):
    if is_available(slot_id):
        reserve(slot_id)
        confirm_booking(slot_id)
        return 'Booked'
    else:
        return 'Unavailable'

What issue can arise if two users call book_slot at the same time for the same slot_id?

medium

A. Both users might get 'Booked' causing double booking

B. The system crashes due to race condition

C. Both users get 'Unavailable' response

D. Only one user can call the function at a time automatically

Solution

1. Step 1: Analyze the code flow for concurrency

   Both users check availability before reservation without locking, so both may see the slot as available.

2. Step 2: Understand race condition effect

   Without locking, both reserve and confirm booking, causing double booking.

3. Final Answer:

   Both users might get 'Booked' causing double booking -> Option A

4. Quick Check:

   Race condition = double booking risk [OK]

Hint: Check-then-act without lock causes double booking [OK]

Common Mistakes:

• Assuming system crashes automatically
• Thinking both get 'Unavailable' response
• Believing function serializes calls automatically

4. In a booking system, the code uses a simple availability check without locking:

if check_availability(slot):
    book(slot)

Users report double bookings. What is the best fix?

medium

A. Add a lock or transaction around availability check and booking

B. Remove availability check to speed up booking

C. Increase server hardware to handle more requests

D. Notify users to book slower

Solution

1. Step 1: Identify the cause of double bookings

   Without locking, multiple users can pass availability check simultaneously causing conflicts.

2. Step 2: Apply concurrency control

   Using locks or transactions ensures only one booking proceeds at a time for the same slot.

3. Final Answer:

   Add a lock or transaction around availability check and booking -> Option A

4. Quick Check:

   Locking fixes concurrency issues [OK]

Hint: Use locks or transactions to fix concurrency bugs [OK]

Common Mistakes:

• Removing availability check causes more errors
• Upgrading hardware does not fix concurrency logic
• Telling users to slow down is not a system fix

5. You are designing a test booking system that must handle thousands of users booking slots concurrently. Which design approach best ensures availability and prevents double bookings?

hard

A. Show all slots as available and accept bookings first come, first served

B. Allow users to book without checks and fix conflicts later manually

C. Use a single global lock for all bookings to serialize requests

D. Use optimistic locking with retries and real-time slot availability updates

Solution

1. Step 1: Understand scalability needs

   Thousands of users require a scalable approach that avoids bottlenecks.

2. Step 2: Evaluate locking strategies

   Single global lock serializes all requests causing delays; manual fixes cause poor user experience.

3. Step 3: Choose optimistic locking with retries

   This approach allows concurrent attempts, detects conflicts, retries, and updates availability promptly.

4. Final Answer:

   Use optimistic locking with retries and real-time slot availability updates -> Option D

5. Quick Check:

   Optimistic locking + updates = scalable concurrency [OK]

Hint: Optimistic locking scales better than global locks [OK]

Common Mistakes:

• Using global lock causes slow system
• Ignoring concurrency leads to double bookings
• Manual conflict fixes harm user experience