In an technical discussion, I had this question of how to maintain a Single instance across nodes, then I answered the below approaches
1) DB based solution
2) Distributed Cache
3) Sharding
4)Maintain the Singleton single Instance in load balancer
Interviewer was expecting something more, since he replied DB based and Cache will work and sharding will not work and no comments on load balancer approach, then further he added that let us assume that DB and Cache approach are not allowed in your application, give me another option I was stuck at this point.
Then I googled and found the following
How to create singleton java class for multiple jvm support?
Singleton in Cluster environment
https://javaarchitectforum.com/2013/02/19/singleton-design-pattern-with-example/
Also found some support from the application servers
http://www.onjava.com/pub/a/onjava/2003/08/20/jboss_clustering.html
http://docs.oracle.com/cd/E12840_01/wls/docs103/cluster/service_migration.html#wp1051458
Kindly help me with your thoughts which would be the best approach to implement single instance(singleton) across nodes
All options will fail if you do not know what you are doing. I'd like to call the singleton an anti-pattern rather than a design pattern, because the way it is often used, is usually recipe for disaster.
Now, lets get to the answer. You should ask the interviewer: why is a singleton really needed? What state really needs to be stored at one specific location? Is this state mutable? What is the concurrency strategy? Will there be mostly writes? Or mostly reads? Does all access have to be synchronised?
You are thinking in the wrong direction because you think a solution to this problem actually exists. Well, you will find a way, but it will be a compromise between concurrent performance and absolute synchronous access.
Now, let us quickly walk through the options you have provided yourself:
1) DB based solution
This could work, but you have to ensure your locking strategy is supported by the database, and that you use it wisely.
2) Distributed Cache
This is essentially the same as a DB based solution. You could even write your own microservice to do this job. You should realise that a distributed cache is exactly the same as a database, only one that is optimised for concurrent reads on the same data (that has an expiration strategy). Keep in mind that if not well-explained, a caching solution may sound as if you are not aware that a cache usually invalidates/expires, and has a just-in-time generation fallback. This may sound as if you did not understood the problem of wanting to have a singleton instance "alive" at all time.
3) Sharding
Sharding is a technique you can you use if your singleton is too big to fit into one database based solution mentioned before. I highly doubt that your singleton will get so big.
4) Maintain the Singleton single Instance in load balancer
This makes your load balancer schizophrenic and is a bad idea. Load balancers are really simple components, and should stay that way.