Bird
Raised Fist0
LLDsystem_design~25 mins

Singleton pattern in LLD - System Design Exercise

Choose your learning style10 modes available
Design: Singleton Pattern Implementation
Design and implement the Singleton pattern for a class in a low-level design context. Out of scope are specific language syntax details or integration with other design patterns.
Functional Requirements
FR1: Ensure only one instance of a class is created throughout the application lifecycle
FR2: Provide a global point of access to the instance
FR3: Support lazy initialization to create the instance only when needed
FR4: Be thread-safe to handle concurrent access in multi-threaded environments
Non-Functional Requirements
NFR1: Instance creation must be efficient with minimal synchronization overhead
NFR2: The pattern should not allow multiple instances even in complex scenarios like serialization or reflection
NFR3: The solution should be simple and easy to understand for maintainability
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
Key Components
Singleton class with private constructor
Static method or property to access the instance
Synchronization mechanisms (locks, volatile variables)
Handling serialization and cloning safeguards
Design Patterns
Lazy Initialization
Double-Checked Locking
Bill Pugh Singleton Implementation
Enum Singleton (language-specific)
Reference Architecture
 +---------------------+
 |   Singleton Class   |
 |---------------------|
 | - private instance  |
 | - private constructor|
 | + getInstance()     |
 +----------+----------+
            |
            v
 +---------------------+
 |  Client Code         |
 +---------------------+
Components
Singleton Class
Any OOP language
Holds the single instance and controls its creation and access
Private Constructor
Language feature
Prevents external instantiation of the class
Static Instance Holder
Static variable
Stores the single instance accessible globally
Synchronization Mechanism
Locks or volatile keyword
Ensures thread-safe lazy initialization
Request Flow
1. Client calls getInstance() method
2. Method checks if instance exists
3. If not, acquires lock to create instance safely
4. Instance is created and stored
5. Lock is released
6. Instance reference is returned to client
7. Subsequent calls return existing instance without locking
Database Schema
Not applicable for Singleton pattern as it is a design pattern for object creation, not data storage.
Scaling Discussion
Bottlenecks
Lock contention during instance creation in highly concurrent environments
Potential performance hit if synchronization is used on every access
Complexity in preventing multiple instances during serialization or cloning
Solutions
Use double-checked locking to minimize synchronization overhead
Use static inner helper class (Bill Pugh method) for lazy and thread-safe initialization without locks
Override serialization methods to prevent creating new instances
Disable cloning or override clone method to return the same instance
Interview Tips
Time: Spend 10 minutes explaining the problem and requirements, 15 minutes designing the pattern with thread safety and lazy initialization, and 5 minutes discussing edge cases like serialization and cloning.
Explain why only one instance is needed and how global access is provided
Discuss thread safety challenges and solutions like double-checked locking
Mention lazy vs eager initialization trade-offs
Highlight how to handle serialization and cloning to maintain singleton property
Show understanding of simplicity and maintainability in design

Practice

(1/5)
1. What is the main purpose of the Singleton pattern in system design?
easy
A. To ensure only one instance of a class exists throughout the application
B. To allow multiple instances of a class with different states
C. To create a new instance every time it is requested
D. To inherit properties from multiple classes

Solution

  1. Step 1: Understand Singleton pattern goal

    The Singleton pattern is designed to restrict a class to a single instance.
  2. Step 2: Compare options with Singleton definition

    Only To ensure only one instance of a class exists throughout the application matches the purpose of Singleton by ensuring one instance exists.
  3. Final Answer:

    To ensure only one instance of a class exists throughout the application -> Option A
  4. Quick Check:

    Singleton = single instance [OK]
Hint: Singleton means one instance only, no duplicates [OK]
Common Mistakes:
  • Thinking Singleton allows multiple instances
  • Confusing Singleton with factory pattern
  • Assuming Singleton creates new instances each call
2. Which of the following is the correct way to declare a Singleton instance method in a class?
easy
A. public static getInstance() { ... }
B. public void getInstance() { ... }
C. private static getInstance() { ... }
D. static getInstance() { ... }

Solution

  1. Step 1: Identify Singleton instance method requirements

    The method to get the Singleton instance must be static and publicly accessible.
  2. Step 2: Analyze options for correct access and static usage

    public static getInstance() { ... } is public and static, which is correct. public void getInstance() { ... } is not static, private static getInstance() { ... } is private, static getInstance() { ... } misses access modifier.
  3. Final Answer:

    public static getInstance() { ... } -> Option A
  4. Quick Check:

    Singleton instance method = public static [OK]
Hint: Singleton instance method must be public and static [OK]
Common Mistakes:
  • Making getInstance() private or non-static
  • Omitting access modifier
  • Using void return type instead of instance
3. Given the following Singleton code snippet, what will be the output?
class Logger {
  static instance = null;
  constructor() {}
  static getInstance() {
    if (this.instance === null) {
      this.instance = new Logger();
    }
    return this.instance;
  }
}
const log1 = Logger.getInstance();
const log2 = Logger.getInstance();
console.log(log1 === log2);
medium
A. undefined
B. true
C. false
D. Error

Solution

  1. Step 1: Understand Singleton instance creation

    The first call to getInstance() creates the instance; the second returns the same instance.
  2. Step 2: Compare references of log1 and log2

    Both variables point to the same instance, so strict equality returns true.
  3. Final Answer:

    true -> Option B
  4. Quick Check:

    Same instance check = true [OK]
Hint: Singleton returns same object reference every time [OK]
Common Mistakes:
  • Assuming new instance created on each call
  • Confusing equality with object content
  • Expecting false due to separate variables
4. Identify the error in this Singleton implementation:
class Config {
  static instance;
  constructor() {}
  static getInstance() {
    if (!instance) {
      instance = new Config();
    }
    return instance;
  }
}
medium
A. No error, code is correct
B. Constructor should be public, not private
C. Missing 'this.' before 'instance' inside getInstance method
D. Static keyword is missing before getInstance method

Solution

  1. Step 1: Check static variable access inside static method

    Static variables must be accessed with 'this.' prefix inside static methods.
  2. Step 2: Identify missing 'this.' usage

    The code uses 'instance' instead of 'this.instance', causing a reference error.
  3. Final Answer:

    Missing 'this.' before 'instance' inside getInstance method -> Option C
  4. Quick Check:

    Static variable access requires 'this.' [OK]
Hint: Use 'this.' to access static variables inside static methods [OK]
Common Mistakes:
  • Ignoring 'this.' prefix for static variables
  • Changing constructor visibility incorrectly
  • Assuming static keyword missing on method
5. You need to design a logging system using the Singleton pattern that supports multi-threaded access safely. Which approach best ensures thread safety while maintaining Singleton behavior?
hard
A. Use a global variable outside the class to store the instance
B. Create a new instance every time getInstance() is called
C. Make the constructor public and static
D. Use double-checked locking with a private static volatile instance variable

Solution

  1. Step 1: Understand thread safety in Singleton

    In multi-threaded environments, multiple threads may create multiple instances if not synchronized.
  2. Step 2: Evaluate options for thread-safe Singleton

    Double-checked locking with a volatile static instance ensures only one instance is created safely.
  3. Final Answer:

    Use double-checked locking with a private static volatile instance variable -> Option D
  4. Quick Check:

    Thread-safe Singleton = double-checked locking [OK]
Hint: Double-checked locking ensures thread-safe Singleton [OK]
Common Mistakes:
  • Ignoring thread safety in Singleton
  • Making constructor public defeats Singleton
  • Using global variables breaks encapsulation
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard