Why booking tests availability and concurrency in LLD - Design It to Understand It

Design: Booking Tests Availability and Concurrency System

Design focuses on booking test slot availability and concurrency handling. Out of scope are payment processing, user authentication, and test result management.

Functional Requirements

FR1: Allow users to view available test slots in real-time

FR2: Enable users to book test slots without double booking

FR3: Handle multiple users trying to book the same slot concurrently

FR4: Provide immediate feedback if a slot is no longer available

FR5: Support cancellation and rescheduling of booked tests

FR6: Ensure data consistency and integrity during concurrent bookings

Non-Functional Requirements

NFR1: Support up to 10,000 concurrent users booking tests

NFR2: API response time p99 under 200ms for availability checks

NFR3: System availability of 99.9% uptime

NFR4: Prevent race conditions and double bookings

NFR5: Data consistency must be maintained even under high concurrency

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway for client requests

Availability service to check and show free slots

Booking service to handle reservations

Database with transactional support

Cache layer for fast availability queries

Locking or concurrency control mechanisms

Design Patterns

Optimistic and pessimistic locking

Eventual consistency vs strong consistency

Cache aside pattern for availability data

Queue-based booking to serialize requests

Idempotency for booking requests

Reference Architecture

Client
  |
  v
API Gateway
  |
  v
+----------------+       +----------------+
| Availability   |<----->| Cache (Redis)  |
| Service        |       +----------------+
+----------------+
  |
  v
+----------------+
| Booking Service |
+----------------+
  |
  v
+----------------+
| Database       |
+----------------+

Components

API Gateway

Nginx or AWS API Gateway

Receives client requests and routes them to appropriate services

Availability Service

Node.js or Python microservice

Checks and returns available test slots using cache and database

Cache

Redis

Stores frequently accessed availability data for fast reads

Booking Service

Java Spring Boot or similar

Handles booking requests with concurrency control and updates database

Database

PostgreSQL with transactions

Stores test slots, bookings, and user data with strong consistency

Request Flow

1. Client requests available test slots via API Gateway.

2. API Gateway forwards request to Availability Service.

3. Availability Service checks Redis cache for slot availability.

4. If cache miss, Availability Service queries Database and updates cache.

5. Client selects a slot and sends booking request via API Gateway.

6. API Gateway forwards booking request to Booking Service.

7. Booking Service starts a database transaction.

8. Booking Service checks slot availability in Database.

9. If available, Booking Service reserves the slot and commits transaction.

10. Booking Service updates cache to reflect new availability.

11. Booking Service responds to client with booking confirmation or failure.

12. Client receives immediate feedback on booking status.

Database Schema

Entities: - TestSlot(id, start_time, end_time, capacity) - Booking(id, user_id, test_slot_id, status, created_at) Relationships: - One TestSlot can have many Bookings - Booking references one TestSlot Constraints: - Unique constraint on (test_slot_id, user_id) to prevent duplicate bookings - Capacity enforced by counting active bookings per TestSlot

Scaling Discussion

Bottlenecks

Database write contention when many users book the same slot simultaneously

Cache inconsistency leading to stale availability data

API Gateway overload under high concurrent requests

Latency increase due to synchronous database transactions

Solutions

Use optimistic locking or row-level locking in database to prevent double booking

Implement cache invalidation or write-through cache to keep availability data fresh

Scale API Gateway horizontally with load balancing

Introduce booking request queue to serialize high-contention bookings

Use read replicas for database to offload read queries

Implement eventual consistency for availability display with strong consistency for booking confirmation

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 15 minutes designing components and data flow, 10 minutes discussing scaling and bottlenecks, and 10 minutes answering questions.

Explain importance of concurrency control to avoid double bookings

Discuss trade-offs between strong and eventual consistency

Highlight use of caching to improve availability check latency

Describe database schema supporting booking constraints

Address scaling challenges and solutions for high concurrency

Show understanding of user experience with immediate booking feedback

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