Reservation and hold system in LLD - System Design Exercise

Design: Reservation and Hold System

Includes reservation and hold management, timeout handling, user notifications. Excludes payment processing and inventory restocking.

Functional Requirements

FR1: Users can reserve items (e.g., seats, products) for a limited time before purchase.

FR2: Users can place a hold on an item to prevent others from reserving it temporarily.

FR3: The system must automatically release holds after a configurable timeout.

FR4: Users can confirm a reservation to finalize the purchase.

FR5: The system should prevent double booking of the same item.

FR6: Support concurrent users making reservations and holds.

FR7: Provide APIs for creating, confirming, canceling reservations and holds.

FR8: Notify users when their hold is about to expire.

Non-Functional Requirements

NFR1: Handle up to 5,000 concurrent users.

NFR2: API response time p99 under 150ms.

NFR3: Availability target 99.9% uptime (max 8.77 hours downtime/year).

NFR4: Reservation hold timeout configurable between 5 to 30 minutes.

NFR5: Data consistency must prevent double booking (strong consistency).

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

❓ Question 7

Key Components

API Gateway for client requests

Reservation and Hold Service for business logic

Database for storing reservations and holds

Cache for quick availability checks

Scheduler or background worker for hold expiration

Notification Service for alerts

Authentication Service

Design Patterns

Optimistic or pessimistic locking to prevent double booking

Event-driven architecture for hold expiration

Cache aside pattern for availability data

Timeout and retry mechanisms

Circuit breaker for external notification service

Reference Architecture

Client
  |
  v
API Gateway
  |
  v
Reservation & Hold Service <--> Cache (Redis)
  |
  v
Database (PostgreSQL)
  |
  v
Scheduler / Background Worker
  |
  v
Notification Service

Components

API Gateway

Nginx or AWS API Gateway

Handles client requests, routes to services, enforces authentication

Reservation & Hold Service

Node.js or Python microservice

Manages reservation and hold logic, enforces business rules

Cache

Redis

Stores current availability and hold status for fast reads

Database

PostgreSQL

Stores persistent reservation and hold records with strong consistency

Scheduler / Background Worker

Celery or AWS Lambda scheduled functions

Checks for expired holds and releases them automatically

Notification Service

Push notification system or email service

Sends alerts to users about hold expiration and reservation status

Authentication Service

OAuth 2.0 provider or custom auth

Verifies user identity before allowing reservation actions

Request Flow

1. User sends a request to reserve or hold an item via API Gateway.

2. API Gateway authenticates the user and forwards the request to Reservation & Hold Service.

3. Service checks cache for item availability.

4. If available, service creates a hold or reservation record in the database using a transaction to ensure no double booking.

5. Service updates cache to reflect new hold/reservation status.

6. Scheduler periodically scans database for expired holds and releases them, updating cache accordingly.

7. Notification Service sends alerts to users before hold expiration.

8. User confirms reservation to finalize purchase, service updates database and cache.

9. User can cancel hold or reservation, service updates records and cache.

Database Schema

Entities: - Item (item_id PK, description, total_quantity) - Reservation (reservation_id PK, user_id FK, item_id FK, quantity, status ENUM('held', 'confirmed', 'canceled'), hold_expiry TIMESTAMP, created_at, updated_at) - User (user_id PK, name, contact_info) Relationships: - One Item can have many Reservations. - One User can have many Reservations. Constraints: - Application logic in transactions ensures sum(quantity where status='held' or status='confirmed') <= total_quantity to prevent double booking. - Index on hold_expiry for efficient expiration queries.

Scaling Discussion

Bottlenecks

Database write contention when many users try to reserve the same item simultaneously.

Cache consistency issues between cache and database.

Scheduler load when scanning large numbers of holds for expiration.

Notification service overload during peak expiration times.

Solutions

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

Implement cache invalidation strategies and use cache aside pattern to keep cache consistent.

Partition holds by item or time window to distribute scheduler workload; use event-driven expiration with message queues.

Throttle notifications and batch alerts; use scalable push notification services.

Interview Tips

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

Clarify reservation vs hold differences and timeout behavior.

Explain how to prevent double booking using database transactions and locking.

Describe the role of cache for performance and how to keep it consistent.

Discuss how scheduler automates hold expiration and user notifications.

Highlight scalability challenges and solutions for concurrency and notification spikes.