Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
List the key non-functional requirements (performance, scalability, reliability, etc.)...
1000 office locations
each office location has 100 rooms
so 100K rooms total
100K to 1M employee total
booking allowed for next 1 to 3 year
approx 1000 days * 1000 minutes each day = 1M minutes * 100K = 100B room minutes of resources
at peak time:
mostly people from same office will book a room, each office has 1K to 10K employee at the max
not more than 100 to 500 will try to book the same room at a given time and not all of the requests will reach at the very same time(practically for this less count)
This is not a very large load for a server or DB to handle
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
1) To book a room for a given time period:
POST booking.com/v1/room/book
input:
roomId
userDetails
timePeriod
output: booking confirmation with a booking ID upon success
2) To view availability of room(s) for a given time period
GET booking.com/v1/room/availability?startTime=20250404103000&endTime=20250404110000
output:
boolean: true/false (or array of booleans for multiple rooms)
3) To view bookings of room(s) for a given time period
GET booking.com/v1/room/bookings?startTime=t1&endTime=t2
output:
array of bookings
each booking has:
startTime
endTime
DELETE booking.com/v1/room/book/{bookingId}
GET booking.com/v1/user/profile/{userId}
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
1st option is preferred for cases where we need to support lot of concurrent operations with low latency.
2nd option is preferred for simplicity and comparatively less load.
Depending on our use case we can choose one.
[Client Apps] → [CDN] → [API Gateway] → [Load Balancer]
↓
┌─────────────────┴─────────────────┐
↓ ↓
[Service Cluster] [Cache Layer]
↓ ↓
┌───────────────┼───────────────┐ [Redis Cluster]
↓ ↓ ↓
[Booking Service] [User Service] [Availability Service]
↓ ↓ ↓
[Notification Queue] [Search Service] [Admin Service]
↓
[Notification Workers]
↓
[Email/SMS Providers]
[Primary DB] ← [Replica DB1] ← [Replica DB2]
4. Core Components
4.1 API Gateway
Purpose: Single entry point, routing, authentication, rate limiting
Tech: Kong, AWS API Gateway, or custom Nginx
Features:
JWT token validation
Request throttling (100 req/min per user)
API versioning
4.2 Load Balancer
Purpose: Distribute traffic across service instances
Tech: HAProxy, AWS ALB, Nginx
Strategy: Round-robin with health checks
Sticky sessions: For stateful operations
4.3 Microservices
Booking Service
Responsibilities: Create, update, cancel bookings
API Endpoints:
POST /bookings - Create booking
GET /bookings/{id} - Get booking details
PUT /bookings/{id} - Modify booking
DELETE /bookings/{id} - Cancel booking
Key Logic:
Distributed locking for double-booking prevention
Transaction management
Conflict resolution
Availability Service
Responsibilities: Check room availability, time slot management
API Endpoints:
GET /rooms/available?startTime=X&endTime=Y&capacity=Z
GET /rooms/{id}/slots?date=X
Optimization: Heavy caching, read replicas
User Service
Responsibilities: Authentication, authorization, profile management
API Endpoints:
POST /auth/login
POST /auth/register
GET /users/{id}
PUT /users/{id}
Notification Service
Responsibilities: Send booking confirmations, reminders, cancellations
Pattern: Asynchronous message queue
Tech: Kafka, RabbitMQ, AWS SQS
Search Service
Responsibilities: Fast full-text search on rooms
Tech: Elasticsearch, Algolia
Features: Filter by location, capacity, amenities, price
4.4 Caching Layer
Redis Cluster for:
Room availability (TTL: 5 minutes)
User sessions (TTL: 24 hours)
Frequent queries (popular rooms, time slots)
Distributed locks (prevent double-booking)
Cache Strategy:
Read-through: Check cache first, then DB
Write-through: Update cache on booking changes
Cache invalidation: On booking/cancellation
4.5 Database Design
Primary Database: PostgreSQL (ACID compliance critical)
Schema:
sql
-- Users table
users (
user_id UUID PRIMARY KEY,
email VARCHAR UNIQUE,
name VARCHAR,
phone VARCHAR,
created_at TIMESTAMP
)
-- Rooms table
rooms (
room_id UUID PRIMARY KEY,
name VARCHAR,
location VARCHAR,
capacity INT,
amenities JSONB,
hourly_rate DECIMAL,
created_at TIMESTAMP
)
-- Bookings table
bookings (
booking_id UUID PRIMARY KEY,
room_id UUID REFERENCES rooms(room_id),
user_id UUID REFERENCES users(user_id),
start_time TIMESTAMP,
end_time TIMESTAMP,
status ENUM('confirmed', 'cancelled', 'completed'),
created_at TIMESTAMP,
CONSTRAINT no_overlap UNIQUE (room_id, start_time, end_time)
)
-- Indexes
CREATE INDEX idx_bookings_room_time ON bookings(room_id, start_time, end_time);
CREATE INDEX idx_bookings_user ON bookings(user_id);
CREATE INDEX idx_rooms_location ON rooms(location);
Read Replicas: 2-3 replicas for read-heavy operations (availability checks)
5. Critical Design Decisions
5.1 Preventing Double-Booking
Problem: Two users booking same room at same time
Solutions:
Option 1: Database-Level Locking
sql
BEGIN TRANSACTION;
SELECT * FROM bookings
WHERE room_id = ? AND start_time < ? AND end_time > ?
FOR UPDATE;
-- If no conflict, insert
INSERT INTO bookings ...;
COMMIT;
Option 2: Distributed Lock (Redis)
python
lock_key = f"room:{room_id}:{date}"
if redis.set(lock_key, "1", nx=True, ex=10):
# Check availability and book
# Release lock
redis.delete(lock_key)
Recommended: Combine both - Redis for speed, DB constraint as safety net
5.2 Handling High Read Load
Cache popular rooms and time slots
Read replicas for availability queries
Database partitioning by date/location
Denormalization for frequently accessed data
5.3 Consistency vs Availability Trade-off
Strong consistency needed for bookings (prevent double-booking)
Eventual consistency acceptable for:
Room search results
Analytics
Notification delivery
6. API Design Examples
Check Availability
text
GET /api/v1/rooms/available
Query params:
- location: string
- startTime: ISO8601
- endTime: ISO8601
- capacity: integer
- amenities: array
Response:
{
"rooms": [
{
"roomId": "uuid",
"name": "Conference Room A",
"capacity": 10,
"location": "Building 1, Floor 2",
"amenities": ["projector", "whiteboard"],
"hourlyRate": 50.00
}
],
"total": 25
}
Create Booking
text
POST /api/v1/bookings
Body:
{
"roomId": "uuid",
"startTime": "2025-11-25T09:00:00Z",
"endTime": "2025-11-25T11:00:00Z",
"purpose": "Team Meeting"
}
Response:
{
"bookingId": "uuid",
"status": "confirmed",
"confirmationCode": "ABC123",
"qrCode": "base64..."
}
7. Scalability Considerations
Horizontal Scaling
Stateless services: Easy to scale behind load balancer
Database sharding: Partition by location or date range
Cache sharding: Redis Cluster with consistent hashing
Vertical Scaling
Upgrade database instances for complex queries
More cache memory for higher hit rates
Auto-scaling
Scale service instances based on CPU/memory metrics
Pre-scale before known peak hours (Monday mornings)
8. Monitoring & Observability
Metrics:
Request latency (p50, p95, p99)
Error rates by service
Cache hit ratio
Database connection pool usage
Queue depth (notification service)
Logging:
Centralized logging (ELK stack, Splunk)
Distributed tracing (Jaeger, Zipkin)
Audit logs for all bookings
Alerts:
High error rates
Database replication lag
Cache failures
Service health checks failing
9. Security Considerations
Authentication: JWT tokens with short expiration
Authorization: Role-based access control (RBAC)
Data encryption: TLS in transit, AES-256 at rest
Rate limiting: Prevent DDoS and abuse
SQL injection prevention: Parameterized queries
PII protection: Hash/encrypt sensitive user data
10. Future Enhancements
ML-based recommendations: Suggest rooms based on history
Dynamic pricing: Surge pricing during peak hours
Mobile apps: iOS/Android native apps
Calendar integration: Sync with Google Calendar, Outlook
Analytics dashboard: Usage patterns, popular rooms
Recurring bookings: Support weekly meetings
Waiting list: Auto-book when cancellation occurs