When to use which structural pattern in LLD - Scalability & System Analysis

Scalability Analysis - When to use which structural pattern

Growth Table: Structural Patterns Usage at Different Scales

Users / Scale	Small (100 users)	Medium (10K users)	Large (1M users)	Very Large (100M users)
Pattern Complexity	Simple patterns like Facade or Adapter for easy integration	Composite and Decorator to manage growing component complexity	Proxy and Flyweight to optimize resource use and access control	Combination of multiple patterns with distributed systems and microservices
System Components	Few components, direct connections	Multiple components, need for flexible composition	High number of components, need for resource sharing and control	Thousands of components, need for scalability and fault tolerance
Performance Needs	Low latency, simple calls	Moderate latency, some caching	High performance, resource optimization critical	Extreme performance, distributed caching, and load balancing
Maintenance	Easy to maintain, minimal abstraction	Moderate abstraction for flexibility	High abstraction to manage complexity	Very high abstraction, automated deployment and monitoring

First Bottleneck

At small scale, the bottleneck is usually the lack of flexibility in component integration, causing slow development or rigid code.

At medium scale, the bottleneck shifts to managing component complexity and communication overhead.

At large scale, resource usage and access control become bottlenecks, especially if patterns do not optimize sharing or proxying.

At very large scale, the bottleneck is system scalability and fault tolerance, requiring distributed pattern implementations and orchestration.

Scaling Solutions

• Small Scale: Use simple structural patterns like Facade to simplify interfaces and Adapter to integrate external systems easily.
• Medium Scale: Employ Composite to build tree structures of components and Decorator to add responsibilities dynamically without changing code.
• Large Scale: Use Proxy to control access and Flyweight to share common data efficiently, reducing memory footprint.
• Very Large Scale: Combine multiple patterns with microservices architecture, distributed caching, and orchestration tools to handle complexity and scale.

Back-of-Envelope Cost Analysis

Requests per second (RPS):

• Small: ~100-500 RPS, handled by single server with simple patterns.
• Medium: ~10K RPS, requires multiple servers and patterns supporting modularity.
• Large: ~100K RPS, needs resource optimization patterns and horizontal scaling.
• Very Large: ~1M+ RPS, demands distributed systems and complex pattern combinations.

Storage and Memory:

• Small: Minimal, simple object structures.
• Medium: Moderate, composite objects and decorators increase memory.
• Large: High, flyweight reduces memory but proxy adds overhead.
• Very Large: Very high, requires distributed caches and memory optimization.

Bandwidth:

• Small: Low, direct calls.
• Medium: Moderate, more component communication.
• Large: High, proxy and flyweight reduce bandwidth but increase complexity.
• Very Large: Very high, requires load balancing and CDN.

Interview Tip

Start by explaining the system scale and complexity. Then describe which structural pattern fits best at each scale and why. Discuss bottlenecks and how patterns help solve them. Finally, mention trade-offs and how you would evolve the design as the system grows.

Self Check

Your system uses a Composite pattern to manage UI components. Traffic grows 10x, and response time increases. What do you do first?

Answer: Analyze if the Composite structure causes deep recursion or heavy object creation. Introduce caching or flatten the component tree. Consider adding Flyweight to share common parts and reduce memory and processing overhead.

Key Result

Structural patterns should be chosen based on system scale and complexity: simple patterns for small systems, composite and decorator for medium scale, proxy and flyweight for large scale, and combined distributed patterns for very large scale systems.