Decentralize — Avoid creating hubs in your microservice implementation

When you break down your big services into microservices, sometimes the tendency is to create a proxy micorservice that everybody can consume for common actions to perform. Another approach that your software engineering group chooses is placing that piece of functionality into a common library that all microservices import in their code and compile into their microservice executable.

What is the right balance without having this proxy microservice becoming a central hub for the overall platform or for this common library to grow too big as the time passes by?

In this article I will focus specifically on this proxy microservice and how to balance it. Let’s assume that you organization has a couple of hundred microservices. Let’s assume that you implemented a single microservice “XYZ-Proxy” that most of the 200 microservices will call. Now imagine the traffic in your production environment is increasing due to your TV commercials and each service in the platform will need to scale; however, since the “XYZ-Proxy” service is being consumed by most of other services, this “XYZ-Proxy” service has to scale even more and it becomes a very central point of failure. Your whole platform is as vulnerable due to this central “XYZ-Proxy” microservice. If multiple instances of that service become unhealthy, you are impacting the health of every other service in the platform.

What can we do in this situation if you still want to use a service to perform this action “XYZ” instead of putting that “XYZ” code into a common library. Let’s assume that your 200 microservices are organized in 10 domain teams that specialize in different domain capabilities (i.e. “billing”, “order fulfillment”) within the platform.

Before I proceed with the recommendation, let me say that some degree of redundancy is very acceptable in the microservice implementation in the interest of?stability?and?scalability.

Option 1:

Each one of these 10 domain teams can be fully autonomous and they can have their own version “XYZ-Proxy-Team1”, “XYZ-Proxy-Team2”, “XYZ-Proxy-TeamN” service with their own team load balancer in front. This decentralizes this capability from the platform level, but still has a bit of centralized theme within its limited domain. It is definitely better as the health of “XYZ-Proxy-Team1” only impact the health of Team1’s microservices.

Option 2:

Another option could be wrapping this “XYZ” capability into a small service that you put into a docker container and then you put that container onto the same compute instance where your microservice runs that needs to consume this “XYZ” capability. This option works well if the “XYZ” capability does not need to perform any interactions with a repository (database or cache).

Option 3:

…. you fill in the blanks

Whichever option you pick, you need to consider the pros and cons and the data integrity if it applies. Don't forget about the cost of the solution running in the cloud. Analyze your situation, choose an option and document the pros/cons of your option and be very transparent within your software engineering community. Remember, there is no perfect architecture. The key thing is to openly have these type of conversations and considerations. Recognizing the limitations/cons of the existing implementation/architecture is half of a solution :)

Thank you for reading this article. Keep geeking out!

Almir Mustafic