How to implement Singleton design pattern in Go ? 🔥
Tags: go, singleton, database
Published: 2022-06-11 13:31:24

# Introduction
Before diving deep into the actual topic, it’s really important to make yourself familiar with the terminologies below. 

## What are Design patterns ?
In software engineering design patterns are solutions to general problems that occurred during the development of a software application faced by the majority of developers. The solutions were standardized over a period of trial and errors.  

## What is Race condition ?
A race condition is a scenario of a program where its behavior depends on relative timing or interleaving of multiple threads or processes. One or more possible outcomes may be undesirable, resulting in a bug. 

## What is the Singleton Design Pattern?
Singleton pattern restricts instantiation of a class or struct to only one single instance at any point of time. Usually its scope is defined as global to allow access of this instance across your application. This design pattern comes really handy in use cases such as **logging**, **caching**, **Thread pool**, **DB connections**,etc.

Singleton pattern could be implemented in one of 2 ways  i.e **Thread Safe** and **Non Thread Safe**.  By the way it's suggested to use thread safe.

### What is Thread safe?
Thread safety is a mechanism to protect your application from entering into Race condition if it is having a shared state being manipulated by multiple threads at the same time.

### What is Non Thread safe?
 It does not check the safety of the threads which makes it faster to run but at the same time, it becomes more unstable for multithreaded applications. It works best for either single thread or sequential applications.

> First let’s see the Non Thread Safety in action

# Non Thread safe implementation in Go
As you can see in the code snippet below, a struct named `SQLConnection` and 3 functions named `mockConnectionNonThreadSafe`, `performConcurrentAction`, `performSequentialAction` are being implemented.

{% embed https://gist.github.com/rahul-yr/e6f48f59b2d05a98a21f19c2a5116ecf %}

In the `mockConnectionNonThreadSafe` function, a `sleep` command is added to just mimic the real world scenario( creation of connection object always takes some arbitrary time). 

To see **non thread safe sequential execution** in action, uncomment the `performSequentialAction` block in main function and run the snippet using this command.

```
go run singleton_pattern/non_thread_safe.go
``` 
![non-thread-safe-sequential.png](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jwk9vwiue7ip1c5669ao.png)

If you get the same output as above, then you have successfully implemented the `non thread safe sequential` program. The output clearly shows that sequential execution works absolutely fine, in fact it’s just created a single instance which is kind of a singleton pattern, but performance is a trade off here because this is a step by step execution which means this program can’t take advantage of multiple cores and threads of a modern day cpu.

To test `non thread safe concurrent` execution, uncomment the `performConcurrentAction` block in main function and run the snippet.
The output will look something similar to this.

![non-thread-safe-concurrent.png](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/32u0s939v5bgq2y8jbj9.png)

If you watch the output closely, you will find that the database instance is continuously modified by every concurrent execution due to some delay in creation of a connection instance ( which is expected in the real-world may be due to network or overload or something else). This is happening because the provided solution is not thread safe, that’s why the connection object is modified by other threads kind of a race condition. In this case we have achieved to successfully utilize the full cpu performance i.e cores and threads, but it’s still far away from the desired output.

> Now it’s finally time to resolve this once for all.

# Thread Safe implementation in Go
Again mostly similar code 1 struct and 3 functions(1 being `mockConnectionThreadSafe`) has been implemented.
As well as a new variable `once` of type `sync.Once`(`Once` is a Golang thread safe built-in struct that is used to implement a singleton pattern) has been added. This variable has a method `Once` which will handle thread safe execution.

{% embed https://gist.github.com/rahul-yr/c2c691354d478c7b7349303e444f6b65 %}
 
Execute this snippet by uncommenting `performConcurrentAction` block in main function.

```
go run singleton_pattern/thread_safe.go
``` 

![thread-safe-concurrent.png](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mqni0qevn9qy339h8cf2.png)

If you have done everything correctly till now, then you will see the database instance being created only once( unlike connection objects being modified by other concurrent executions in case of non thread safe) even though we are using concurrent executions.
The race condition has been handled and it’s working as expected by utilizing the full power of modern day CPU's. Congrats⭐ on top of that it’s absolutely thread safe.

Now you can access the same instance variable wherever you want without any conflicts.

# Summary
Awesome 🔥, you have successfully completed this tutorial. I would 💝 to hear your feedback and comments on the great things you're gonna build with this. 
If you are struck somewhere feel free to comment. I am always available.

Please find the complete code at [github](https://github.com/rahul-yr/learn-go-concepts/tree/main/singleton_pattern)