Availability checking in LLD - System Design Exercise

Design: Availability Checking System

Design covers availability checking, booking, cancellation, and notification. Out of scope: payment processing, user authentication, and detailed UI design.

Functional Requirements

FR1: Allow users to check availability of resources (e.g., rooms, equipment, or services) for specific time slots

FR2: Support concurrent availability queries from up to 10,000 users

FR3: Allow users to book available resources and update availability in real-time

FR4: Provide notifications if requested resource is unavailable

FR5: Support cancellation and modification of bookings

FR6: Ensure data consistency to prevent double bookings

Non-Functional Requirements

NFR1: System must respond to availability queries within 200ms (p99 latency)

NFR2: System should have 99.9% uptime (less than 8.77 hours downtime per year)

NFR3: Handle up to 1,000 bookings per minute

NFR4: Support eventual consistency for availability updates with strong consistency for booking confirmation

NFR5: Scale horizontally to handle increasing load

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Load Balancer

Availability Service

Booking Service

Database (Relational or NoSQL)

Cache Layer (e.g., Redis) for fast availability queries

Message Queue for asynchronous notifications

Notification Service

Design Patterns

Cache-Aside pattern for availability data

Eventual consistency with strong consistency for booking confirmation

CQRS (Command Query Responsibility Segregation) to separate read and write models

Optimistic locking or transactions to prevent double booking

Publish-Subscribe pattern for notifications

Reference Architecture

          +-------------+          +----------------+
          |   Clients   | <------> | API Gateway /  |
          +-------------+          | Load Balancer  |
                                   +-------+--------+
                                           |
                    +----------------------+--------------------+
                    |                                           |
          +---------v---------+                       +---------v---------+
          | Availability       |                       | Booking Service   |
          | Service (Cache +   |                       | (Handles booking, |
          | DB)               |                       | cancellation)     |
          +---------+---------+                       +---------+---------+
                    |                                           |
                    |                                           |
          +---------v---------+                       +---------v---------+
          | Cache (Redis)     |                       | Database (SQL or  |
          | for fast reads    |                       | NoSQL with strong |
          +-------------------+                       | consistency)     |
                                                      +---------+---------+
                                                                |
                                                      +---------v---------+
                                                      | Message Queue      |
                                                      | (Notifications)    |
                                                      +---------+---------+
                                                                |
                                                      +---------v---------+
                                                      | Notification       |
                                                      | Service            |
                                                      +-------------------+

Components

API Gateway / Load Balancer

Nginx or AWS ALB

Distributes incoming client requests to backend services and handles SSL termination

Availability Service

Custom microservice in chosen language

Handles availability queries using cache and database to provide fast responses

Booking Service

Custom microservice

Processes booking requests, ensures no double booking, updates database and cache

Cache (Redis)

Redis

Stores availability data for fast read access to reduce database load

Database

PostgreSQL or MongoDB

Stores persistent booking and availability data with transactional support

Message Queue

RabbitMQ or Kafka

Queues notification events asynchronously to decouple booking from notification

Notification Service

Custom microservice or third-party service

Sends notifications to users about booking status or availability

Request Flow

1. 1. Client sends availability query to API Gateway.

2. 2. API Gateway forwards request to Availability Service.

3. 3. Availability Service checks Redis cache for requested resource and time slot.

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

5. 5. Availability Service returns availability status to client.

6. 6. Client sends booking request to API Gateway.

7. 7. API Gateway forwards booking request to Booking Service.

8. 8. Booking Service checks availability (cache and database) to prevent double booking.

9. 9. Booking Service uses transaction or optimistic locking to reserve resource in database.

10. 10. Booking Service updates cache to reflect new availability.

11. 11. Booking Service publishes booking event to Message Queue.

12. 12. Notification Service consumes event and sends confirmation or failure notification to client.

13. 13. Client can send cancellation or modification requests handled similarly by Booking Service.

Database Schema

Entities: - Resource: id (PK), name, type, description - Booking: id (PK), resource_id (FK), user_id, start_time, end_time, status - User: id (PK), name, contact_info Relationships: - Resource 1:N Booking (one resource can have many bookings) - User 1:N Booking (one user can have many bookings) Constraints: - Booking time ranges must not overlap for the same resource - Status indicates active, cancelled, or completed bookings

Scaling Discussion

Bottlenecks

Cache becoming a single point of failure or bottleneck under heavy read load

Database write contention when many bookings happen simultaneously for the same resource

Message queue overload if notification volume spikes

API Gateway limits under very high concurrent connections

Solutions

Use Redis clustering and replication to scale cache and improve availability

Implement sharding or partitioning in database by resource or time to reduce contention

Use multiple message queue partitions and consumers to handle high notification throughput

Deploy multiple API Gateway instances behind a load balancer and use autoscaling

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Clarify resource types and booking rules before designing

Explain caching strategy to meet latency requirements

Discuss consistency models and how to prevent double booking

Highlight asynchronous notifications to improve user experience

Address scaling challenges and solutions realistically

Practice

1. What is the main purpose of availability checking in system design?

easy

A. To create backups of system data

B. To increase the speed of data processing

C. To encrypt user data for security

D. To determine if a resource is free or ready to use

Solution

1. Step 1: Understand the concept of availability checking

   Availability checking is about verifying if a resource like a room, item, or slot is free to be used or booked.

2. Step 2: Identify the main goal

   The main goal is to know if the resource is ready or free, not about speed, security, or backups.

3. Final Answer:

   To determine if a resource is free or ready to use -> Option D

4. Quick Check:

   Availability checking = resource readiness [OK]

Hint: Availability checking means resource is free or not [OK]

Common Mistakes:

• Confusing availability with performance optimization
• Mixing availability with security features
• Thinking availability means data backup

2. Which of the following code snippets correctly checks if a room is available given a list of booked rooms booked_rooms = [101, 102, 103] and a requested room requested_room = 104?

easy

A. if requested_room in booked_rooms:
print('Available')

B. if requested_room == booked_rooms:
print('Available')

C. if requested_room not in booked_rooms:
print('Available')

D. if requested_room > booked_rooms:
print('Available')

Solution

1. Step 1: Understand the list and requested room

   booked_rooms contains rooms already taken: 101, 102, 103. requested_room is 104.

2. Step 2: Check correct condition for availability

   Room is available if requested_room is NOT in booked_rooms. So, 'if requested_room not in booked_rooms' is correct.

3. Final Answer:

   if requested_room not in booked_rooms: print('Available') -> Option C

4. Quick Check:

   Not in booked_rooms means available [OK]

Hint: Check 'not in' to confirm availability [OK]

Common Mistakes:

• Using 'in' instead of 'not in' to check availability
• Comparing equality of a number to a list
• Using greater than operator on list

3. Given the following code, what will be the output?

booked_slots = {"9AM": True, "10AM": False}
requested_slot = "10AM"
if not booked_slots.get(requested_slot, False):
    print("Slot Available")
else:
    print("Slot Booked")

medium

A. Slot Available

B. Slot Booked

C. KeyError

D. No output

Solution

1. Step 1: Understand the dictionary and requested slot

   booked_slots maps times to True (booked) or False (free). "10AM" is False, meaning free.

2. Step 2: Evaluate the condition

   booked_slots.get("10AM", False) returns False. 'not False' is True, so it prints "Slot Available".

3. Final Answer:

   Slot Available -> Option A

4. Quick Check:

   False means free, so output is Slot Available [OK]

Hint: False means free slot, so print available [OK]

Common Mistakes:

• Assuming True means available instead of booked
• Expecting KeyError when key exists
• Ignoring default value in get()

4. Identify the bug in the following availability check code:

def is_available(stock, requested):
    if requested > stock:
        return True
    else:
        return False

print(is_available(5, 10))

medium

A. The function should return False when requested is greater than stock

B. The function is correct and returns True

C. The condition should be 'requested <= stock' to return True

D. The function should compare 'stock > requested' instead

Solution

1. Step 1: Analyze the condition logic

   Current code returns True if requested > stock, meaning more requested than available stock.

2. Step 2: Correct logic for availability

   Availability means stock should be enough or more than requested. So, if requested > stock, return False.

3. Final Answer:

   The function should return False when requested is greater than stock -> Option A

4. Quick Check:

   Requested > stock means not available [OK]

Hint: Availability means stock >= requested, else False [OK]

Common Mistakes:

• Returning True when requested exceeds stock
• Confusing greater than with less than
• Not testing with example values

5. You are designing an availability checking system for a hotel booking platform. Which approach best ensures high availability and scalability when checking room availability in real-time?

hard

A. Use a centralized database with locking to check and update availability synchronously

B. Cache availability data in memory with periodic sync to the database and use optimistic concurrency

C. Check availability by scanning all booking records on every request without caching

D. Allow double booking and resolve conflicts manually later

Solution

1. Step 1: Understand requirements for high availability and scalability

   System must respond quickly and handle many requests without blocking.

2. Step 2: Evaluate options for real-time availability checking

   Cache availability data in memory with periodic sync to the database and use optimistic concurrency uses caching and optimistic concurrency, reducing database load and avoiding locks, improving scalability and availability.

3. Final Answer:

   Cache availability data in memory with periodic sync to the database and use optimistic concurrency -> Option B

4. Quick Check:

   Caching + optimistic concurrency = scalable availability [OK]

Hint: Cache data and use optimistic concurrency for scalable availability [OK]

Common Mistakes:

• Using locking causing bottlenecks
• Scanning all records causing slow response
• Allowing double booking causing user issues