Reservation and hold system in LLD - Scalability & System Analysis

Scalability Analysis - Reservation and hold system

Growth Table: Reservation and Hold System

Users	Requests per Second	Database Load	Cache Usage	Network Traffic	System Behavior
100 users	~10-50 RPS	Single DB instance handles writes and reads	Minimal caching needed	Low bandwidth	System runs smoothly on a single server
10,000 users	~1,000 RPS	DB under moderate load, some read replicas needed	Cache frequently accessed data (holds, availability)	Moderate bandwidth, load balancer introduced	Latency may increase, need for caching and replicas
1,000,000 users	~50,000 RPS	DB write bottleneck, sharding required	Heavy caching, distributed cache cluster	High bandwidth, CDN for static content	Complex coordination for holds, distributed locking
100,000,000 users	~5,000,000 RPS	Multiple DB clusters, global sharding	Multi-level caching, edge caches	Very high bandwidth, global CDN, message queues	Eventual consistency, asynchronous processing

First Bottleneck

The database is the first bottleneck because reservation and hold systems require strong consistency for writes to avoid double booking. As user requests increase, the DB write throughput limits the system's ability to process holds and reservations in real-time.

Scaling Solutions

• Read Replicas: Offload read queries like availability checks to replicas to reduce DB load.
• Caching: Use distributed caches (e.g., Redis) for frequently accessed data such as seat availability and hold status.
• Sharding: Partition the database by resource (e.g., venue, event) to spread write load across multiple DB instances.
• Horizontal Scaling: Add more application servers behind load balancers to handle increased traffic.
• Distributed Locking: Implement distributed locks or consensus protocols to prevent double booking in a distributed environment.
• Asynchronous Processing: Use message queues for non-critical updates to improve responsiveness.
• CDN: Use CDNs for static content and possibly for caching availability snapshots to reduce load.

Back-of-Envelope Cost Analysis

• At 10,000 users with ~1,000 RPS, a single DB instance (~5,000 QPS capacity) can handle writes and reads with caching.
• At 1,000,000 users (~50,000 RPS), DB write capacity is exceeded; sharding and multiple DB clusters needed.
• Storage: Each reservation record ~1 KB; 1M reservations = ~1 GB storage, manageable with modern DBs.
• Network bandwidth: 1,000 RPS with ~1 KB payload = ~1 MB/s; scales linearly with users.
• Cache memory: Redis cluster with 10s of GB RAM to hold hot data for fast access.

Interview Tip

Start by clarifying system requirements and scale. Identify the critical consistency needs for reservations. Discuss the database as the first bottleneck and propose caching and sharding. Explain how distributed locking prevents double booking. Finally, mention asynchronous processing and CDN use for scalability and performance.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Introduce read replicas and caching to offload read queries, then consider sharding the database to distribute write load and prevent bottlenecks.

Key Result

The database write capacity is the first bottleneck in a reservation and hold system. Scaling requires caching, read replicas, and sharding combined with distributed locking to maintain consistency and prevent double booking.