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

Scalability Analysis - When to use which creational pattern

Growth Table: Usage of Creational Patterns at Different Scales

Scale	Object Creation Needs	Pattern Usage	Impact on System
100 users	Few objects, simple creation	Simple Factory or direct instantiation	Minimal overhead, easy to maintain
10K users	More objects, need for flexibility	Factory Method or Builder for complex objects	Improved code reuse, easier object management
1M users	High object creation, performance critical	Singleton for shared resources, Prototype for cloning	Reduces resource usage, faster object creation
100M users	Massive scale, distributed systems	Abstract Factory with dependency injection, Singleton with distributed locks	Ensures consistency, scalable object management

First Bottleneck

At small scale, object creation overhead is negligible. As users grow, the bottleneck becomes inefficient object creation causing CPU and memory strain. For example, creating many complex objects repeatedly slows down the system. Without proper patterns, code becomes hard to maintain and extend.

Scaling Solutions

• Simple Factory: Use for small scale to centralize object creation.
• Factory Method: Use when subclasses decide object types, improving flexibility.
• Builder: Use for complex objects with many parts, improving readability and maintainability.
• Singleton: Use for shared resources to avoid multiple instances and save memory.
• Prototype: Use to clone objects efficiently instead of creating from scratch.
• Abstract Factory: Use in large systems to create families of related objects, supporting scalability and consistency.
• Combine with Dependency Injection: To manage object lifecycles and dependencies cleanly at scale.

Back-of-Envelope Cost Analysis

• At 10K users, creating 10 objects per user per second = 100K objects/sec.
• Without patterns, each creation costs CPU cycles and memory allocation.
• Using Prototype can reduce creation time by cloning, saving CPU.
• Singleton reduces memory by sharing instances.
• At 1M users, object creation can reach millions per second, stressing CPU and memory.
• Proper patterns reduce overhead and improve throughput.

Interview Tip

Start by explaining the problem of object creation at scale. Describe each creational pattern briefly and when it fits best. Use examples like shared resources (Singleton), complex object building (Builder), or flexible object families (Abstract Factory). Discuss bottlenecks and how patterns solve them. Show understanding of trade-offs and scalability.

Self Check

Your system creates 1000 objects per second. Traffic grows 10x to 10,000 objects per second. What do you do first?

Answer: Identify if object creation is a bottleneck. If yes, apply Prototype to clone objects or Singleton to share instances where possible. Consider Builder for complex objects to optimize creation steps. This reduces CPU and memory usage, improving scalability.

Key Result

Creational patterns help manage object creation efficiently as system scales, preventing CPU and memory bottlenecks by reusing, cloning, or centralizing object creation.

Practice

1. Which creational pattern is best when you need only one instance of a class throughout the application?

easy

A. Singleton pattern

B. Factory pattern

C. Builder pattern

D. Prototype pattern

Solution

1. Step 1: Understand the requirement for a single instance

   The question asks for a pattern that ensures only one instance of a class exists.

2. Step 2: Match the pattern to the requirement

   Singleton pattern restricts instantiation to one object and provides a global access point.

3. Final Answer:

   Singleton pattern -> Option A

4. Quick Check:

   Single instance = Singleton [OK]

Hint: Single instance? Think Singleton pattern [OK]

Common Mistakes:

• Confusing Factory with Singleton
• Using Builder for single instance
• Thinking Prototype creates single instance

2. Which creational pattern allows creating different types of objects without specifying their concrete classes directly?

easy

A. Singleton pattern

B. Factory pattern

C. Builder pattern

D. Adapter pattern

Solution

1. Step 1: Identify the pattern for flexible object creation

   The question wants a pattern that creates objects without exposing the creation logic.

2. Step 2: Match the pattern to the description

   Factory pattern provides an interface to create objects but lets subclasses decide which class to instantiate.

3. Final Answer:

   Factory pattern -> Option B

4. Quick Check:

   Flexible object creation = Factory [OK]

Hint: Flexible creation? Use Factory pattern [OK]

Common Mistakes:

• Choosing Singleton for flexible creation
• Confusing Builder with Factory
• Selecting Adapter which is not creational

3. Consider this code snippet using the Builder pattern:

class CarBuilder {
  constructor() {
    this.car = new Car();
  }
  setColor(color) {
    this.car.color = color;
    return this;
  }
  setWheels(wheels) {
    this.car.wheels = wheels;
    return this;
  }
  build() {
    return this.car;
  }
}

const car = new CarBuilder().setColor('red').setWheels(4).build();
console.log(car.color, car.wheels);

What will be the output?

medium

A. red 4

B. undefined undefined

C. red undefined

D. Error: Car is not defined

Solution

1. Step 1: Check if Car class is defined

   The code uses new Car() but Car class is not defined anywhere, causing a runtime error.

2. Step 2: Understand the consequence of missing class

   Since Car is undefined, the code throws a ReferenceError before any properties are set.

3. Final Answer:

   Error: Car is not defined -> Option D

4. Quick Check:

   Missing class definition = ReferenceError [OK]

Hint: Check if all classes are defined before use [OK]

Common Mistakes:

• Assuming output is 'red 4' without Car class
• Ignoring missing class error
• Confusing Builder pattern with Factory output

4. You have a Singleton class implemented as below:

class Logger {
  constructor() {
    if (Logger.instance) {
      return Logger.instance;
    }
    this.logs = [];
    Logger.instance = this;
  }
  log(message) {
    this.logs.push(message);
  }
}

What is the main issue with this implementation?

medium

A. It creates a new instance every time

B. It does not store logs properly

C. It does not prevent multiple instances

D. It lacks a method to retrieve logs

Solution

1. Step 1: Analyze Singleton enforcement

   The constructor returns existing instance if present, but the implementation does not fully prevent multiple instances.

2. Step 2: Identify the issue in JavaScript context

   In JavaScript, this pattern works but can be bypassed by other means; better to use static method to get instance.

3. Final Answer:

   It does not prevent multiple instances -> Option C

4. Quick Check:

   Singleton enforcement flaw = It does not prevent multiple instances [OK]

Hint: Singleton needs controlled instance creation [OK]

Common Mistakes:

• Thinking logs are not stored
• Assuming new instance is always created
• Ignoring missing retrieval method

5. You are designing a system to create complex meal orders with many optional parts (drink, main dish, dessert). Which creational pattern is most suitable and why?

hard

A. Builder pattern, because it simplifies creating complex objects step-by-step

B. Singleton pattern, because only one meal order should exist

C. Factory pattern, because it creates different meal types without specifying details

D. Prototype pattern, because it clones existing meal orders

Solution

1. Step 1: Understand the complexity of the object

   Meal orders have many optional parts and require step-by-step construction.

2. Step 2: Match pattern to complex object creation

   Builder pattern is designed to build complex objects step-by-step, allowing optional parts to be added flexibly.

3. Final Answer:

   Builder pattern, because it simplifies creating complex objects step-by-step -> Option A

4. Quick Check:

   Complex object with options = Builder [OK]

Hint: Complex object? Use Builder pattern [OK]

Common Mistakes:

• Choosing Singleton for multiple orders
• Confusing Factory with Builder for complex objects
• Using Prototype without cloning need