HLD: Design a restaurant reservation system
FR
The system shall allow customers to search restaurants by location, cuisine, date, time, and number of guests.
The system shall display real-time table availability for a selected restaurant and time slot.
The system shall allow customers to create a reservation by providing guest details and preferred time.
The system shall prevent double-booking of tables for overlapping time slots.
The system shall allow customers to modify or cancel an existing reservation within restaurant-defined policies.
The system shall send reservation confirmation and updates via email/SMS/notification.
The system shall allow restaurant staff to manage table configurations, operating hours, and reservation rules.
The system shall support walk-in reservations and manual bookings by restaurant staff.
The system shall maintain reservation history for customers and restaurants.
The system shall handle no-shows, late arrivals, and auto-release of tables after a configurable grace period.
NFR
Scalability – The system shall support high concurrent users and scale horizontally during peak dining hours.
Availability – The system shall be highly available (≥ 99.9%) to ensure uninterrupted booking access.
Consistency – The system shall ensure strong consistency for reservation and table availability to prevent double booking.
Performance – Search and reservation confirmation APIs shall respond within < 300 ms under normal load.
Reliability – The system shall guarantee reservation durability with no data loss once a booking is confirmed.
Security – The system shall protect user and restaurant data using authentication, authorization, and encryption (at rest and in transit).
API design
1. Search Restaurants
GET /api/v1/restaurants/search
Request
?location=Bangalore
&date=2026-01-20
&time=19:00
&guests=4
&cuisine=Italian
Response
{
"restaurants": [
{
"restaurantId": "R101",
"name": "Olive Garden",
"rating": 4.3
}
]
}
2. Get Table Availability
GET /api/v1/restaurants/{restaurantId}/availability
Request
?date=2026-01-20
&time=19:00
&guests=4
Response
{
"availableSlots": [
{
"tableId": "T12",
"capacity": 4
}
]
}
3. Create Reservation
POST /api/v1/reservations
Request
{
"restaurantId": "R101",
"tableId": "T12",
"date": "2026-01-20",
"time": "19:00",
"guests": 4,
"customerName": "Shashank",
"customerPhone": "9999999999"
}
Response
{
"reservationId": "RES789",
"status": "CONFIRMED"
}
4. Get Reservation Details
GET /api/v1/reservations/{reservationId}
Response
{
"reservationId": "RES789",
"restaurantId": "R101",
"tableId": "T12",
"status": "CONFIRMED"
}
5. Modify Reservation
PUT /api/v1/reservations/{reservationId}
Request
{
"time": "20:00",
"guests": 3
}
Response
{
"status": "UPDATED"
}
6. Cancel Reservation
DELETE /api/v1/reservations/{reservationId}
Response
{
"status": "CANCELLED"
}
7. Restaurant Table Management
POST /api/v1/restaurants/{restaurantId}/tables
Request
{
"tableId": "T15",
"capacity": 6
}
Response
{
"status": "TABLE_ADDED"
}
8. Walk-in / Staff Booking
POST /api/v1/reservations/walkin
Request
{
"restaurantId": "R101",
"guests": 2
}
Response
{
"reservationId": "RES900",
"status": "CONFIRMED"
}
Databases
1. Relational Database (MySQL / PostgreSQL)
Used for: Core transactional data (strong consistency)
Tables
restaurants
restaurant_id (PK)
name
location
cuisine
opening_time
closing_time
rating
created_at
tables
table_id (PK)
restaurant_id (FK)
capacity
is_active
reservations
reservation_id (PK)
restaurant_id (FK)
table_id (FK)
customer_id
reservation_date
start_time
end_time
status -- CONFIRMED, CANCELLED, NO_SHOW
created_at
customers
customer_id (PK)
name
phone
email
created_at
2. NoSQL Database (Cassandra / DynamoDB)
Used for: High-volume reads, availability lookup, horizontal scaling
Table: table_availability
restaurant_id (PK)
date (CK)
time_slot (CK)
table_id
capacity
is_available
Why:
Fast reads for availability search
Avoids expensive joins during peak traffic
3. Cache (Redis)
Used for: Low-latency reads, temporary locks
Keys
Availability Cache
key: availability:{restaurantId}:{date}:{time}
value: list<tableId>
TTL: 60 seconds
Reservation Lock
key: lock:{restaurantId}:{tableId}:{date}:{time}
TTL: 2–5 minutes
Why:
Prevents double booking
Improves performance under concurrency
4. Search Database (Elasticsearch / OpenSearch)
Used for: Restaurant discovery & filtering
Index: restaurants_index
{
"restaurantId": "R101",
"name": "Olive Garden",
"location": "Bangalore",
"cuisine": ["Italian"],
"rating": 4.3
}
5. Analytics / Logging DB (ClickHouse / BigQuery)
Used for: Reporting, insights, demand analysis
Table: reservation_events
event_id
restaurant_id
reservation_id
event_type -- CREATED, CANCELLED, NO_SHOW
timestamp
Summary Table (Easy to Remember)
| Database Type | Purpose |
| -------------------- | -------------------------- |
| MySQL / Postgres | Transactions & consistency |
| Cassandra / DynamoDB | Availability & scale |
| Redis | Cache & locking |
| Elasticsearch | Search & filtering |
| ClickHouse | Analytics & reporting |
Microservices
1. API Gateway
Responsibilities
Entry point for all client requests
Authentication, authorization, rate limiting
Routes requests to internal services
2. User Service
Responsibilities
Manage customer profiles
Store contact details and preferences
Fetch reservation history for users
Database
Relational DB (MySQL / Postgres)
3. Restaurant Service
Responsibilities
Manage restaurant metadata
Handle cuisines, location, operating hours
Manage table configurations
Database
Relational DB
Elasticsearch for restaurant search
4. Availability Service
Responsibilities
Calculate real-time table availability
Read/write availability slots
Handle temporary table holds
Database
NoSQL (Cassandra / DynamoDB)
Redis for caching & locks
5. Reservation Service
Responsibilities
Create, modify, cancel reservations
Ensure strong consistency
Prevent double booking
Database
Relational DB (MySQL / Postgres)
6. Notification Service
Responsibilities
Send SMS / Email / Push notifications
Reservation confirmations & updates
Database
No DB (async processing)
7. Admin / Staff Service
Responsibilities
Walk-in reservations
Manual booking & overrides
No-show handling
Database
Relational DB
8. Analytics Service
Responsibilities
Reservation metrics
Peak hour analysis
No-show rate tracking
Database
ClickHouse / BigQuery
Service Interaction Flow (Create Reservation)
Client
|
API Gateway
|
Reservation Service
|
Availability Service
| \
Redis Lock Cassandra Availability
|
Reservation Service
|
Relational DB (Save Reservation)
|
Notification Service (Async)
Communication Pattern
InteractionTypeClient → GatewayRESTGateway → ServicesRESTReservation → AvailabilityRESTReservation → NotificationEvent / AsyncServices → DBDirect
Key Design Decisions (Interview Points)
Availability is isolated to handle peak traffic independently
Redis locks prevent race conditions during booking
Event-driven notifications avoid blocking reservation flow
Separate analytics service prevents OLTP performance impact