[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

Submissions

Displaying Solutions with Scores Ranging from 1 to 10