| 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 |
Room type hierarchy in LLD - Scalability & System Analysis
Start learning this pattern below
Jump into concepts and practice - no test required
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.
- 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.
- 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.
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.
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.
Practice
Room type hierarchy in system design?Solution
Step 1: Understand the concept of hierarchy
A hierarchy groups items by common traits, making management simpler.Step 2: Apply to room types
Using a base class for shared features and subclasses for specifics avoids duplication and eases updates.Final Answer:
To organize rooms by shared and unique features for easier maintenance -> Option BQuick Check:
Hierarchy = Organize by features [OK]
- Confusing hierarchy with flat lists
- Duplicating properties in every room class
- Ignoring shared features in base class
Room with a subclass ConferenceRoom in a typical object-oriented design?Solution
Step 1: Identify correct syntax for inheritance
In many modern languages,extendsis used to inherit from a base class.Step 2: Check each option
class Room {}; class ConferenceRoom extends Room {} uses correct syntax:class ConferenceRoom extends Room {}. Others use incorrect or incomplete syntax.Final Answer:
class Room {}; class ConferenceRoom extends Room {} -> Option AQuick Check:
Inheritance syntax = extends [OK]
- Using 'inherits' instead of 'extends'
- Missing curly braces for class body
- Incorrect parentheses in class declaration
class Room:
def __init__(self, name):
self.name = name
class Bedroom(Room):
def __init__(self, name, bed_size):
super().__init__(name)
self.bed_size = bed_size
room = Bedroom('Master', 'King')
print(room.name, room.bed_size)What will be the output?
Solution
Step 1: Trace object creation
CreatingBedroom('Master', 'King')calls Bedroom's constructor, which calls Room's constructor with 'Master'.Step 2: Check printed attributes
room.nameis 'Master' from Room;room.bed_sizeis 'King' from Bedroom.Final Answer:
Master King -> Option DQuick Check:
Subclass calls base, attributes set correctly [OK]
- Assuming subclass overwrites base attributes
- Forgetting to call super().__init__
- Confusing attribute names
class Room:
def __init__(self, name):
self.name = name
class MeetingRoom(Room):
def __init__(self, name, capacity):
self.capacity = capacity
room = MeetingRoom('Boardroom', 20)
print(room.name, room.capacity)What is the issue here?
Solution
Step 1: Check constructor chaining
MeetingRoom's constructor sets capacity but does not callsuper().__init__(name), sonameis not set.Step 2: Understand effect on attributes
Without base constructor call,room.nameis missing, causing error or undefined behavior.Final Answer:
Missing call to base class constructor causes room.name to be undefined -> Option CQuick Check:
Always call base __init__ in subclass [OK]
- Assuming base constructor runs automatically
- Ignoring missing attributes in subclass
- Confusing syntax errors with logic errors
Room, Bedroom, ConferenceRoom, and Suite. Suites can have multiple bedrooms and a living area. Which design approach best models this?Solution
Step 1: Analyze relationships
Suite is a special Room that contains multiple Bedrooms and a living area, so it should inherit from Room.Step 2: Model composition
Suite should have a list of Bedroom objects (composition) to represent multiple bedrooms, plus its own living area attributes.Final Answer:
Make Suite inherit from Room and include a list of Bedroom objects plus living area -> Option AQuick Check:
Use inheritance + composition for complex types [OK]
- Using inheritance to model 'has-many' relationships
- Ignoring composition for complex room types
- Making unrelated classes inherit incorrectly
