Room type hierarchy in LLD - Scalability & System Analysis

Scalability Analysis - Room type hierarchy

Growth Table: Room Type Hierarchy

Scale	Number of Room Types	Hierarchy Depth	Queries per Second (QPS)	Storage Size	Notes
100 users	10-50	2-3 levels	50 QPS	~1 MB	Simple hierarchy, in-memory caching sufficient
10,000 users	100-500	3-5 levels	500 QPS	~10 MB	Database indexing needed, caching important
1,000,000 users	1,000-5,000	4-7 levels	5,000 QPS	~100 MB	Read replicas, sharding, and distributed cache required
100,000,000 users	10,000+	5-10 levels	50,000+ QPS	1+ GB	Microservices, advanced sharding, CDN for static data

First Bottleneck

At small scale, the database becomes the first bottleneck due to complex hierarchical queries and joins needed to resolve room type relationships.

As users grow, the CPU and memory on application servers strain to process deep hierarchy traversals and caching.

At very large scale, network bandwidth and data partitioning challenges arise due to large hierarchy data and frequent updates.

Scaling Solutions

• Database indexing: Add indexes on parent-child relations to speed up queries.
• Caching: Use in-memory caches (e.g., Redis) to store frequently accessed hierarchy data.
• Read replicas: Distribute read load across multiple database replicas.
• Sharding: Partition room types by category or region to reduce query scope.
• Microservices: Separate hierarchy management into dedicated services for scalability.
• CDN: Cache static hierarchy data closer to users to reduce latency.

Back-of-Envelope Cost Analysis

• At 1M users with 5,000 QPS, database must handle ~5,000 complex hierarchy queries per second.
• Storage for hierarchy data grows from ~1MB at 100 users to ~100MB at 1M users.
• Network bandwidth for hierarchy data updates and queries can reach several hundred MB/s at large scale.
• Memory needed for caching hierarchy data increases proportionally with hierarchy size.

Interview Tip

Start by explaining the hierarchy structure and typical queries. Then discuss how load and data size grow with users.

Identify the database as the first bottleneck due to complex joins and suggest caching and indexing.

Explain horizontal scaling with read replicas and sharding as user base grows.

Finally, mention microservices and CDN for very large scale to reduce latency and isolate components.

Self Check

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

Answer: Add read replicas to distribute read queries and reduce load on the primary database.

Key Result

The database is the first bottleneck due to complex hierarchical queries; scaling requires caching, indexing, read replicas, and sharding to handle growth from thousands to millions of users.