Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A creational design pattern that makes sure a class has exactly one instance and gives the whole program one shared way to reach it, used for things like a connection pool or a config object.
In short
The singleton pattern is a design pattern that makes sure a class has exactly one instance and gives the whole program one shared way to reach it. It suits a resource that must exist once, such as a connection pool or a logger, but it hides dependencies and makes tests harder.
In short
The singleton pattern is a design pattern that makes sure a class has exactly one instance and gives the whole program one shared way to reach it. It suits a resource that must exist once, such as a connection pool or a logger, but it hides dependencies and makes tests harder.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Singleton Pattern across a run of lessons, not one page. These 4 alone are about 79 minutes of step-by-step reading, every one with a quiz.
Ensure a class has only one instance, the most loved and hated design pattern in software.
When multiple services share one database, the anti-pattern that sometimes makes sense.
Removing an instance on purpose, the race between the pool update and the shutdown, and what in-flight leaves out.
How bug bounty programs pay outside researchers to find security bugs. Compares platforms, shows the report lifecycle, and covers when to launch one.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
Ive started this course by accident - LLM advised me this site. When I passed few free lessons, I had no doubt - this course should be bought. And I did it with special pleasent price and it was best decision of the month. Content is great, interesting to read and with a lot of practial cases (what makes it different from other souces and books) I hope to teach all the lessons, that will be my supergoal. Glad that I found this resource and speacial Thank You to Roni Das - Great Job!
You own this course
Continue with Singleton Patternpay once,
yours for life
A design pattern is a named, reusable answer to a problem that keeps coming back in code. The singleton is one of the 23 patterns in the 1994 Gang of Four book, and it belongs to the creational family. Creational patterns are about how objects get made. See design patterns for the whole map.
The Gang of Four intent has two parts. First, ensure a class has only one instance. Second, provide a global point of access to it. An instance is one object built from a class. A global point of access is one place any code can call to get that object.
So the idea is small. Make one thing, use it everywhere, and make sure nobody creates a second one by accident.
The Singleton lesson opens with a real kind of bug. A fintech team was chasing a memory leak. The app used 12 GB of RAM and kept growing. The cause: every HTTP request created a new database connection pool. A connection pool is a set of open database connections that requests share. Each new pool opened 10 connections, and hundreds of requests per second soon meant thousands of connections hitting the database.
The fix was one line. Create the pool once and reuse it everywhere. That is the singleton idea.
The lesson lists the usual candidates, each with its reason:
A classic singleton has three parts. A private field holds the one instance. The constructor is hidden, so outside code cannot call new on the class. A static method, usually named getInstance(), is the only way in.
The first call to getInstance() finds the field empty, builds the object and stores it. Every later call finds the field full and returns the same object. Building the object only when it is first needed is called lazy initialization. It means no memory is used until someone actually asks.
The figure below is the lesson's Logger example. Without a singleton, Object A and Object B each call new Logger(), and two instances write to the same log file and conflict. With a singleton, both call getInstance() and get the same Logger, so writes go through one object.
logger.js (Node.js)
class Logger {
static #instance = null;
static created = 0;
static getInstance() {
if (Logger.#instance === null) {
Logger.#instance = new Logger();
Logger.created += 1;
}
return Logger.#instance;
}
log(msg) {
console.log(`[log] ${msg}`);
}
}
const a = Logger.getInstance(); // Object A asks for the logger
const b = Logger.getInstance(); // Object B asks for the logger
a.log("order placed");
b.log("payment captured");
console.log("same object:", a === b);
console.log("instances created:", Logger.created);Output, captured 2026-10-04 (node logger.js)
[log] order placed
[log] payment captured
same object: true
instances created: 1
Drawn from the lesson Singleton Pattern.
Two callers, one object, one construction. This JavaScript version needs no lock, because one Node.js process runs your code on a single thread. In a language with real threads, it does need one, as the next section shows.
Picture two threads, A and B, calling getInstance() at the same moment. Both see an empty field. Both build an object. Now you have two singletons, which is exactly the bug the pattern was meant to stop.
The classic fix is double-checked locking, and the lesson walks through it step by step. The method checks the field once without a lock. If it is empty, the thread takes a lock and checks again inside it. Thread A gets the lock, sees the field is still empty, and builds the object. Thread B waits on the lock. When B gets in, its second check finds the object, so it skips building and returns it.
The first check exists for speed. After the object exists, no thread ever touches the lock again, and each call is a plain field read. The second check exists for correctness.
Each language has its own gotcha. In Java the field must be declared volatile, or a thread can see a half-built object. Bill Pugh's write-up on the Java memory model explains why, and notes that volatile fixes it from Java 5 on. A Java enum with one value avoids the problem, because the JVM builds enum constants itself. Go has sync.Once, which runs a function exactly once across all goroutines. In Node.js, a module is cached after the first require, so exporting one instance from a module already acts as a singleton.
An anti-pattern is a common answer that causes more problems than it solves. The lesson is honest that the singleton earned part of this reputation. It names three costs.
The benefits are real too. You get controlled access to a shared resource, lazy initialization, and a one-instance guarantee that does not depend on every developer remembering a rule.
Most production codebases now keep the single instance but drop the global access. They use dependency injection, or DI. In DI, a class lists what it needs in its constructor, and a framework part called the container builds those objects and passes them in.
The container creates one instance and hands the same reference to everyone who asks. You still get one connection pool. But each class declares the dependency openly, and a test can pass in a fake. NestJS makes this the default: one provider instance is shared across the whole app. .NET does the same with AddSingleton, and Spring's default bean scope is singleton.
Without a DI container, as in many Go programs, a factory with a cache does the job. A function builds the object once, stores it, and returns the stored one after that. Tests can replace the function. Go's sync.Once is exactly this. The lesson's comparison sums it up:
Use one when the thing truly must exist once per process. A second copy would waste a scarce resource or corrupt shared state. And your codebase has no DI container to hold it for you.
Skip it when the only reason is convenient global access. Skip it when the object holds state that tests will need to reset. And skip the hand-written version when your framework already has a singleton scope, because the framework solves thread safety and testability for you.
The singleton sits next to the factory in the creational family. A factory decides which class to build, and it can also cache what it builds. Read creational design patterns to compare them, or the factory pattern page and the Factory Pattern lesson.
To step through the lifecycle and the two-thread race one frame at a time, the Singleton Pattern lesson is the next step.
NestJS
Every provider is a singleton by default: one instance is shared across the entire application, created by the DI container at startup.
Go sync.Once
The standard library type that runs a function exactly once, the usual Go way to build a shared instance lazily and safely.
Node.js modules
A module is cached after its first load, so every require of the same file returns the same exported object.
Because it hides dependencies, leaks state between tests and ties code to one concrete class. A class that calls getInstance() inside a method does not show that need in its constructor. Most teams keep the one-instance behavior but get it from a dependency injection container instead.
A database connection pool is the classic one. The Singleton lesson describes an app that built a new pool of 10 connections on every request, used 12 GB of RAM and flooded the database. Creating one pool and sharing it fixed the leak. Loggers and configuration managers are other common examples.
Anything that builds a second instance breaks it. Two threads racing through an unlocked getInstance() is the common one. In Java, reflection can call a private constructor, and serialization or cloning can produce a copy. A Java enum singleton resists all three, because the language forbids creating enum instances by reflection and serialization never duplicates an enum constant.
A singleton controls how many instances exist: exactly one. A factory controls which class gets built: the caller asks for an interface and the factory picks the concrete class. They solve different problems and can be combined, for example a factory that caches the instance it builds.
No. A static class is just a group of functions with no object. A singleton is a real object, so it can implement an interface, hold state and be passed around. That is also why a DI container can manage a singleton but not a static class.
Checked against these on .
Design Patterns
Named, reusable solutions to problems that keep coming up in object-oriented code, such as creating objects, wrapping interfaces or reacting to events. The classic catalogue of 23 was published by the Gang of Four in 1994.
Factory Pattern
A creational design pattern where one method or class decides which concrete object to build, so the calling code asks for an object by type or config instead of calling a constructor directly.
Creational Design Patterns
The family of design patterns about how objects get created: Singleton, Factory Method, Abstract Factory, Builder and Prototype. They hide the construction details from the code that uses the object.
Connection Pool
A cache of reusable database connections that avoids the overhead of opening and closing a new connection for every query. Critical for high-throughput applications.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
This page explains the idea. The "Singleton Pattern" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Singleton Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.