Singleton Pattern
Singleton: start from the problem
See the responsibilities
Several parts of one application need the same registry. Passing different registries can create inconsistent local views. A Singleton provides access to one instance within its defined scope, but that scope is often much smaller than people assume.
This is a creational pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Singleton addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
The pattern controls instance creation and provides access to that instance. In a module-based application, a module can hold a shared local object. Define whether the intended scope is a module, process, worker or another container.
Our example returns the same registry object inside one execution context. Starting another process can create another registry. This is not a distributed leader election mechanism or a cluster-wide uniqueness guarantee.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const getRegistry = (() => {
const registry = new Map();
return () => registry;
})();
getRegistry().set('writer', 'csv');
console.log(getRegistry() === getRegistry());
console.log(getRegistry().get('writer'));Expected output
true
csvChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use a scoped shared instance only when that lifetime is intentional, such as a local registry. Dependency injection can supply the same instance explicitly without global access.
Global mutable state complicates tests, dependencies and concurrent access. Initialization and shutdown need coordination in applicable runtimes. A singleton connection is not necessarily a safe or scalable connection pool.
Distinguish the neighbouring patterns
Leader election coordinates ownership across machines. Singleton limits a local object instance. Dependency injection concerns how consumers receive dependencies and can coexist with a shared lifetime.
Follow coordination across processes, finding service instances, controlled creation choices to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Singleton, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside controlled creation choices.
Reaching the recap and completing the quizzes are separate milestones.