We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
A developer at a mid-size fintech company was debugging a memory leak. The application was eating 12 GB of RAM and growing. After hours of profiling, they found the culprit: every single request was creating a new database connection pool. Not a new connection, a new pool. Hundreds of requests per second, each spinning up its own pool with 10 connections. Within minutes, they had thousands of connections hammering the database.
The fix took one line of code. Instead of creating a new pool on every request, they created it once and reused it everywhere. That one-instance-shared-everywhere pattern? That's the Singleton.
It's the simplest design pattern in the Gang of Four catalog, and also the most controversial. Some engineers love it. Others consider it an anti-pattern. Both sides have valid points, and by the end of this lesson you'll understand why.
The Singleton pattern guarantees that a class has exactly one instance throughout the lifetime of your application, and provides a global point of access to it.
That's it. No fancy abstractions. No complex inheritance hierarchies. Just: make one thing, use it everywhere, and make sure nobody accidentally creates a second one.
Real things that should be singletons:
| Thing | Why Only One? |
|---|---|
| Database connection pool | Creating multiple pools wastes connections and can crash the DB |
| Logger | You want all logs going through one coordinated system |
| Configuration manager | App config should be loaded once and shared, not re-parsed per request |
| Thread pool | Multiple pools compete for OS threads and cause contention |
| Cache manager | Multiple caches mean duplicate data and inconsistent reads |
The pattern sounds trivial, but the implementation has subtle traps, especially in multi-threaded environments. Let's look at how it actually works.
It is easy and good
“It is really nice and good Please join the course”