Have you ever found yourself dealing with an object that needs to be shared across multiple parts of your application—perhaps a database connection, a WebSocket client, or a configuration manager?
How do you manage such an object so that it remains consistent and accessible throughout the application or process lifecycle? This is where the Singleton Design Pattern comes into play.
Overview
Singleton is a creational design pattern , which is a category of design patterns that deals with the different problems that come with the native way of creating objects with the new keyword or operator.
The Singleton Design Pattern focuses on solving two primary problems:
- How can we provide a global point of access to our instance?
 - How can we ensure that a class or a specific type of objects has only one instance?
 
It can simplify and standardize the way we are managing a specific kind or type of global state such as database connections, WebSocket clients, caching services, or anything that we need to persist and mutate in memory during the entire application lifecycle.
How can we implement the Singleton Design Pattern?
The above schema translates into this TypeScript class:
TypeScript example
class Singleton {
  private static instance: Singleton
  // other properties...
  public authorName: string
  private constructor({ authorName }: { authorName: string }) {
    this.authorName = authorName
  }
  public static getInstance(params) {
    if (!this.instance) {
      this.instance = new Singleton(params)
    }
    return this.instance
  }
  // other methods...
}
- The class should define a static property for storing the uniquely sharable instance.
 
The keyword static means that the instance object is not associated with the instances of the class but with the class definition itself.
- The constructor of the class should be marked as private. The only way for getting an instance of our class is by calling the 
getInstancestatic method. 
const instance = Singleton.getInstance({ authorName: "Sidali Assoul" })
// let's imagine
const instance1 = Singleton.getInstance({ authorName: "Sidali Assoul" }) // "Sidali Assoul"
const instance2 = Singleton.getInstance({ authorName: "John Doe" }) // "Sidali Assoul"
We can make use of the above class by calling the static method getInstance which is associated with the Singleton class.
The getInstance method guarantees us that we are always getting the same instance even if we instantiated our class multiple times in different locations of our codebase.
So both variables (instance1 and instance2) share the same singleton instance.
First Practical Scenario
Prisma is a well-known ORM in the JavaScript ecosystem. To use Prisma in your application, you have to import a PrismaClient then instantiate an object from it.
import { PrismaClient } from "@prisma/client"
export const prismaClient = new PrismaClient()
The Prisma client connects to the database in a lazy manner, or in other terms, only when you first try to query or mutate some entity.
import { prismaClient } from "@/db"
const users = await prismaClient.user.findMany() // query on the users table
Every time the prismaClient gets imported in a file, a new instance will be made out of the PrismaClient. Hence, many database connections will be established every time we use those instances.
export const prismaClient = new PrismaClient() // a new instance is created every time it gets imported then used.
Many open database connections will degrade the performance of your application and may even lead to database shutdown because databases typically can only handle a limited number of connections.
The Singleton Design Pattern can help us prevent such an issue by avoiding having more than one instance of the PrismaClient class and by providing a single point to access it via the PrismaClientSingleton.getInstance() static method.
import { PrismaClient } from "@prisma/client"
class PrismaClientSingleton {
  private static instance: PrismaClient
  private constructor() {}
  public static getInstance(): PrismaClient {
    if (!PrismaClientSingleton.instance) {
      PrismaClientSingleton.instance = new PrismaClient()
    }
    return PrismaClientSingleton.instance
  }
}
export default PrismaClientSingleton
Second Practical Scenario
Another practical scenario we will be going through is an in-memory rate limiter service.
Users or hackers can spam a specific endpoint by making a ton of requests to it. This can lead to vulnerabilities, unexpected costs, or server failures.
To prevent that, we can implement a basic in-memory rate limiter service.
The service should be limiting the number of requests per IP address for a specific timing window interval (60 seconds, for example).
class RateLimiterService {
  private static instance: RateLimiterService
  private requests: Map<string, { count: number; lastRequestTime: number }>
  private readonly limit: number // Maximum number of requests
  private readonly window: number // Time window in milliseconds
  private constructor(limit: number = 5, window: number = 60000) {
    this.requests = new Map()
    this.limit = limit
    this.window = window
  }
  // Method to get a unique singleton instance
  public static getInstance(): RateLimiterService {
    if (!RateLimiterService.instance) {
      RateLimiterService.instance = new RateLimiterService()
    }
    return RateLimiterService.instance
  }
  public isRateLimited(ip: string): boolean {
    const currentTime = Date.now()
    const userRequestData = this.requests.get(ip)
    if (userRequestData) {
      const isExpired =
        currentTime - userRequestData.lastRequestTime > this.window
      if (isExpired) {
        userRequestData.count = 1
        userRequestData.lastRequestTime = currentTime
        return false
      } else {
        userRequestData.count++
        if (userRequestData.count > this.limit) {
          return true
        }
        return false
      }
    } else {
      this.requests.set(ip, { count: 1, lastRequestTime: currentTime })
      return false
    }
  }
}
export default RateLimiterService
The RateLimiterService class stores a map which tracks the number of requests (requests[ip].count) being made by a specific user identified by an IP address (the map key) in a given timing window (requests[ip].lastRequestTime).
Our RateLimiterService is meant to be used globally, or in other terms, we don't want to reset the internal state values consisting of the requests map, limit, and window variables every time the RateLimiterService gets imported.
Conclusion
The Singleton Design Pattern is a powerful tool for effectively managing shared resources in our applications
Key takeaways:
- Singleton ensures a class has only one instance and provides a global point of access to it.
 - It's useful for managing shared resources like database connections, configuration settings, or caches.
 - Practical applications include optimizing database connections with ORMs like Prisma and implementing rate limiting services.
 
Contact
If you have any questions or want to discuss something further feel free to Contact me here.
Happy coding!


    
Top comments (5)
i can tell this is very good example of singleton
I have looked for this solution many times. Finally I found the solution explained very well.
Good article!
Glad you found it helpful!
thanks for this article. the scenarios are very useful and informative <3
You're welcome!
Thank you, @akaanuzman