Problem — Exactly One Instance - Singleton Pattern | OneNoughtOne

0/246

System Design (LLD)Singleton Pattern

Singleton Pattern

LevelIntermediate

Duration90 mins

TopicSingleton Pattern

1 / 5

Problem — Exactly One Instance

The Single Instance Imperative

In software systems, certain resources are inherently singular. There's one application configuration in memory at any moment. There's one logging subsystem receiving messages from all components. There's one connection pool managing database access. There's one print spooler controlling the printer queue.

These aren't arbitrary constraints—they emerge from fundamental characteristics of the resources being managed. When multiple instances of such components exist simultaneously, the system doesn't just become inefficient; it becomes incorrect. Data inconsistencies, resource conflicts, deadlocks, and undefined behavior follow.

The Singleton pattern addresses this problem by ensuring a class has exactly one instance and providing a global point of access to it. But before we explore the solution, we must deeply understand the problem—because misidentifying what requires singleton semantics leads to one of the most common anti-patterns in object-oriented design.

What You Will Learn

By the end of this page, you will understand the genuine scenarios that demand exactly one instance, distinguish them from cases where singletons are misapplied, comprehend the failure modes when single-instance invariants are violated, and recognize the problem categories that naturally lead to Singleton consideration.

Why Exactly One?

The requirement for exactly one instance isn't a stylistic preference—it emerges from objective constraints in the problem domain. Let's categorize the fundamental reasons:

1. Shared Mutable State Consistency

When multiple components must share mutable state, having multiple copies of that state creates split-brain problems. If component A updates an in-memory configuration cache, but component B reads from a different cache instance, they operate on divergent data. This isn't a performance issue—it's a correctness issue.

Consider an application settings manager. If two instances exist:

User changes a setting via the UI → Instance A updates
Background service reads the setting → Instance B returns stale value
The system behavior becomes non-deterministic

2. Resource Exclusivity

Certain resources require exclusive access for correct operation. File handles, hardware interfaces, network sockets binding to specific ports—these cannot be meaningfully duplicated. The operating system enforces single-holder semantics for these resources; your application must reflect this reality.

A print spooler exemplifies this. If two spooler instances exist:

Both attempt to send jobs to the printer
Print jobs interleave incorrectly
Documents become corrupted
Or one instance fails while the other succeeds unpredictably

3. Global Coordination Requirements

Some components exist to coordinate activity across an entire application or system. Thread pools, event dispatchers, service registries—these derive their utility from being the single point of coordination. Multiple coordinators create partitioned systems where coordination fails.

An event bus demonstrates this. If two event bus instances exist:

Publishers on bus A are invisible to subscribers on bus B
Events appear to be "lost"
The promised decoupling between publishers and subscribers breaks down

Categories of Single-Instance Requirements
Category	Core Constraint	Failure Mode if Violated	Example
Shared State	One source of truth	Split-brain, data inconsistency	Configuration cache, session state
Resource Exclusivity	Resource can only have one holder	Resource contention, corruption	Print spooler, file lock manager
Global Coordination	Single coordination point	Partitioned/isolated subsystems	Event bus, service locator
Identity Preservation	One canonical representation	Identity comparison failures	Factory registries, type metadata
Cost Constraints	Expensive to create/maintain	Resource exhaustion	Connection pools, caches

Real-World Scenarios Demanding Singletons

Let's examine concrete scenarios where the single-instance requirement is genuine and inviolable:

Scenario 1: Application Configuration Manager

Modern applications load configuration from multiple sources—files, environment variables, command-line arguments, remote configuration services. This configuration must be:

Loaded once at startup (expensive operation)
Cached in memory for fast access
Consistent across all components
Potentially refreshable without restart

If multiple configuration instances exist, components reading configuration at different times might see different values—even without any configuration change occurring. A component initialized early gets instance A; a component initialized later gets instance B with different cached values.

configuration-problem.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// The Problem: Multiple ConfigManager instances cause inconsistency
 
class ConfigManager {
    private settings: Map<string, string>;
    
    constructor() {
        this.settings = new Map();
        this.loadFromFile(); // Expensive operation
    }
    
    private loadFromFile(): void {
        // Simulate loading from disk - takes 100ms, reads current file state
        console.log("Loading configuration from disk...");
        // File might change between calls!
    }
    
    get(key: string): string | undefined {
        return this.settings.get(key);
    }
    
    set(key: string, value: string): void {
        this.settings.set(key, value);
        // Other instances won't see this change!
    }
}
 
// Problem demonstration:
const configA = new ConfigManager(); // Loads file at time T1
const configB = new ConfigManager(); // Loads file at time T2 (might differ)
 
// Component A updates config
configA.set("theme", "dark");
 
// Component B reads—doesn't see the update!
console.log(configB.get("theme")); // undefined or stale value
 
// This is not a caching problem—it's a fundamental design flaw
// There should be ONE source of truth, not two divergent copies

Scenario 2: Database Connection Pool

Database connections are expensive to create (network handshakes, authentication, setup). Applications maintain connection pools to amortize this cost. The pool must:

Limit total connections (databases have limits)
Track which connections are in use
Return connections for reuse
Handle connection failures and recreation

If multiple pools exist, each tracks only its own connections. Total connections exceed limits. Connections can't be shared across pools. Resource utilization becomes unpredictable.

connection-pool-problem.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// The Problem: Multiple connection pools exceed database limits
 
class ConnectionPool {
    private maxConnections: number;
    private activeConnections: number = 0;
    
    constructor(maxConnections: number) {
        this.maxConnections = maxConnections;
        console.log(`Created pool with max ${maxConnections} connections`);
    }
    
    acquire(): Connection | null {
        if (this.activeConnections >= this.maxConnections) {
            return null; // Pool exhausted
        }
        this.activeConnections++;
        return new Connection();
    }
    
    release(conn: Connection): void {
        this.activeConnections--;
    }
}
 
// Database allows 10 connections total
const DATABASE_LIMIT = 10;
 
// Problem: Multiple pools each think they can use full limit
const poolA = new ConnectionPool(DATABASE_LIMIT); // Thinks it has 10
const poolB = new ConnectionPool(DATABASE_LIMIT); // Also thinks it has 10
 
// Service A acquires 8 connections from poolA
// Service B acquires 8 connections from poolB
// Total: 16 connections attempted
// Database rejects connections after 10
// But neither pool knows about the other's usage!
 
// Even worse: when one pool is exhausted but other has free connections,
// components can't access the available connections

Scenario 3: Logging System

A centralized logging system aggregates messages from all application components. It must:

Maintain consistent log file handles
Ensure log ordering across threads
Apply uniform formatting and filtering
Manage log rotation and archival

Multiple logger instances create fragmented logs. Messages from different components appear in different files. Timestamps become unreliable for debugging. Log rotation corrupts ongoing writes.

logging-problem.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// The Problem: Multiple logger instances fragment logs
 
class Logger {
    private logFile: FileHandle;
    private buffer: string[] = [];
    
    constructor(filename: string) {
        // Each instance opens its own file handle
        this.logFile = openFile(filename, 'append');
    }
    
    log(message: string): void {
        const timestamp = new Date().toISOString();
        const formatted = `[${timestamp}] ${message}
`;
        this.buffer.push(formatted);
        
        // Buffer and flush logic...
    }
    
    flush(): void {
        // Writes to file
        this.logFile.write(this.buffer.join(''));
        this.buffer = [];
    }
}
 
// Problem: Each component creates its own logger
// UserService.ts
const userLogger = new Logger('app.log');
userLogger.log('User logged in'); // Written at position A
 
// PaymentService.ts  
const paymentLogger = new Logger('app.log');
paymentLogger.log('Payment processed'); // Written at position B
 
// If both flush simultaneously:
// - Race condition between file handles
// - Log entries interleave at character level
// - Output: "[2024-01-15T10:30:00.000Z] User [2024-01-15T10:30:00.001Z] Payment..."
// - Logs become unreadable
 
// Even without races, buffering means messages appear out of order
// across different instances

The Cost of Multiple Instances

When single-instance requirements are violated, the failures are often subtle and intermittent—the worst kind of bugs. Let's analyze the failure modes systematically:

Memory and Resource Waste

Each instance duplicates state and resources. A configuration manager loading 50 MB of data into memory does so for every instance. Ten components each creating their own instance? 500 MB consumed instead of 50 MB. This might seem like a simple efficiency issue, but in resource-constrained environments or at scale, it causes outages.

Failure Modes When Single-Instance Invariant Violated

•Split-Brain State — Different components see different versions of 'shared' state. Updates made by one component are invisible to others. System behavior becomes non-deterministic.
•Resource Exhaustion — Each instance holds its own resources (connections, file handles, threads). Total resource usage exceeds limits designed for single instance.
•Coordination Failure — Components expecting to communicate through a shared coordinator end up talking to different coordinators. Messages and events are lost.
•Identity Breakdown — Object identity comparisons fail when they shouldn't. Two 'Configuration' references should be the same object; if they're different instances, equality checks fail unexpectedly.
•Initialization Redundancy — Expensive initialization (loading files, establishing connections, building caches) happens multiple times. Startup becomes slow; resources are wasted.
•Inconsistent Behavior — Components initialized at different times capture different snapshots. The same code path produces different results depending on which instance is used.

The Debugging Nightmare

These failures are particularly insidious because they're often intermittent. In testing with small data and single-threaded execution, everything works. In production with concurrent access and large data, a component happens to create a new instance at just the wrong moment, and suddenly the system produces incorrect results—but only occasionally, and only under load.

Distinguishing Genuine Singleton Need

Not every class that developers implement as a Singleton genuinely requires singleton semantics. Overuse of Singleton is one of the most common design pattern abuses. Let's establish clear criteria for genuine need:

The Correctness Test

Ask: "If two instances of this class existed simultaneously, would the system produce incorrect results—not just be inefficient, but actually wrong?"

Configuration Manager: Yes—different components might see different config values
Logger: Yes—logs would be fragmented and corrupted
Utility class with no state: No—multiple instances are harmless
Database connection: No—multiple connections are fine; it's the pool that should be singular

The Resource Test

Ask: "Does this class manage a resource that physically cannot be duplicated?"

Print Spooler: Yes—there's one printer queue
File Lock Manager: Yes—file locks are OS-level singular
HTTP Client: No—you can have multiple HTTP clients
Random Number Generator: No—multiple generators are valid (and often desired)

The Coordination Test

Ask: "Does this class exist to coordinate activity across otherwise independent components?"

Event Bus: Yes—the point is a single coordination point
Service Registry: Yes—services must register in one place to be discoverable
String Formatter: No—formatters don't coordinate anything

Genuine Singleton Candidates

•Application configuration managers
•Connection pools (the pool, not connections)
•Thread pools and executor services
•Logging subsystems
•Hardware interface managers
•Print spoolers and job queues
•Application-wide event buses
•Service locators/registries
•Caches with expiration policies

Often Misidentified as Singletons

•Utility/helper classes (should be static)
•Stateless services (can be multiple)
•Value objects (should be immutable)
•Factory instances (unless holding state)
•HTTP/API clients (usually fine multiple)
•Database entities (definitely multiple)
•Business objects (User, Order, etc.)
•Data transfer objects
•Strategy implementations

The Litmus Test

If you're unsure whether something needs to be a Singleton, imagine two developers independently create instances in different parts of the codebase. If the system still works correctly, it doesn't need to be a Singleton. If the system breaks or produces wrong results, Singleton semantics are genuinely required.

The Problem Statement Formalized

We can now formalize the problem that the Singleton pattern addresses:

The Problem:

Given a class C where:

Exactly one instance of C should exist during application lifetime
Many components distributed across the codebase require access to this instance
The instance must be created at some point (lazily or eagerly)
The creation of multiple instances would cause incorrect behavior or resource conflicts

We need a mechanism that:

Guarantees only one instance is ever created
Provides global access to that instance from anywhere in the code
Handles the timing of instance creation appropriately
Works correctly in concurrent/multi-threaded environments
Makes the singleton nature of the class explicit and enforceable

Why normal class instantiation fails:

Standard class instantiation offers no instance count guarantees. Any code with access to the class can call new ClassName() and create an additional instance. Even well-intentioned developers might accidentally create new instances:

accidental-instantiation.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// Without Singleton enforcement, nothing prevents multiple instances
 
class ConfigManager {
    private settings: Map<string, string> = new Map();
    
    constructor() {
        this.loadConfiguration();
    }
    
    private loadConfiguration(): void {
        // Load from files, environment, etc.
    }
    
    getSetting(key: string): string | undefined {
        return this.settings.get(key);
    }
}
 
// Developer A in UserModule
const userConfig = new ConfigManager(); // Creates instance 1
 
// Developer B in PaymentModule (different file, doesn't know about A)
const paymentConfig = new ConfigManager(); // Creates instance 2!
 
// Developer C knows there should be one, but has no way to access it
// without passing it through the entire call chain
function processOrder(config: ConfigManager) {
    // Requires explicit dependency injection through all callers
}
 
// The language provides no protection against creating multiple instances
// The class design doesn't communicate "there should be only one"
// Developers must rely on documentation and discipline—which fails at scale

The Constraints We Must Satisfy:

Instantiation Control — The class itself must control when instances are created, not external code
Global Accessibility — The single instance must be accessible from anywhere without passing it through all intermediate function calls
Lazy or Eager Creation — Support both "create on first access" and "create at startup" strategies
Thread Safety — In concurrent environments, concurrent first access must still result in only one instance
Testability — The solution should ideally allow substitution for testing (though classic Singleton struggles here)

This is the problem space the Singleton pattern addresses. In the next page, we'll explore the solution: making the constructor private and providing a static accessor.

Summary

We've established a rigorous understanding of when and why exactly one instance of a class is genuinely required:

Key Takeaways

•Single-instance requirements emerge from problem domains — shared state consistency, resource exclusivity, and global coordination naturally demand exactly one instance.
•Multiple instances cause correctness failures, not just inefficiency — split-brain state, resource exhaustion, and coordination failures are bugs, not performance issues.
•Not everything is a Singleton — utility classes, stateless services, and value objects are commonly misidentified as needing singleton semantics.
•The litmus test is correctness — if two instances existing simultaneously would produce incorrect results, Singleton may be appropriate.
•Standard instantiation offers no guarantees — without explicit control, developers can accidentally create multiple instances despite good intentions.

Next Steps

Now that we understand the problem—why exactly one instance is sometimes required and what fails when this invariant is violated—we're ready to explore the solution. The next page covers the classic Singleton implementation: private constructor with static accessor.