Too many microservices?

Today we'll see about what happens when we have too many microservices in the system and how to effectively send data across each microservice in a large ecosystem.

?? I am building a Backend-as-a-Service (BaaS) developer platform - Cosmocloud, where you can build your complex APIs in just a few minutes! ??

Cosmocloud for Startups - a new program to provide free credits upto 6 months to build and scale your app on production. Reach out now!

Why opt for Microservices?

Creating your product as a group of Microservices allows you to develop / maintain and scale each independent part of the product separately without the need to change too much dependant code of other modules and services.

What are too many Microservices?

It’s the point where many microservices are trying to communicate with each other and it builds a large graph type network of the same microservices. The scale of thousands of API requests per minute from one service to other, relaying the same data to multiple microservices at the same time for real time analysis would create a very bad architecture and huge load on the system itself.

For example, imagine a university system, where you have multiple services –

1. Student portal – Handling everything for student centric information like registration to finance and stuff.
2. Library portal – Handling everything happening inside the library – Book registration, lending and returning the issued books, etc.
3. Academic portal – Handling everything related to student’s marks, etc.
4. Hostel portal – Handling everything hostel related such as check in, check out, room number, laundry information etc.
5. etc.

Now imagine that there are thousands of new students registering on the Student Portal at the same moment and hundreds of different portals that needs this information. The same information needs to be communicated to other portals to create their profiles / setup information (In real scenario, it might not be this busy system but imagine a single portal catering to every university/college on this planet).

Now there are multiple ways to handle this scale –

Multi Microservice Communication Architectures

Batch Poll and Pull Architecture

Solution Approach

All portals will regularly call the Student Portal’s APIs to poll and fetch new information, on regular intervals such as every 5 minutes to 15 minutes.

Problems

When we have thousands of new students and hundreds of portals and poll the service say every 5 minutes, then there is a lag of 5 minutes for the information to be reflected on each of the portal. This may be okay, but in real scenario we like to keep things consistent and near real time updates. If we bring the interval down to say 1 minute, the load on the system would be very high as there would be too many API calls to Student Portal and the network bandwidth could be overloaded.

Push and Relay Architecture – Sender’s Responsibility

Solution Approach

The student portal in this case would send an API call to every portal on every new student registration.

Problems

When we have thousands of new students and hundreds of portals, there would be hundreds of calls for every student to each portal and would led to hundreds of thousands calls per minute.

If this was not enough, then the responsibility of registering and relaying to every new service made would be of the senders and this would cause huge scalability issues.

Now what should we do?

We might have an alternate to Push and Relay Architecture and can use the concept in a better way. The bottlenecks for above were the HTTP calls and new service registration. HTTP calls are inherently tightly coupled, meaning we will have to wait for each call to get the acknowledgement from the receiver.

As making the above API calls asynchronous could solve a bit, still waiting for all these network calls will have huge network impact. Also, the sender would need to keep track of who to send the data to and still register new services as they are built.

Fire and Forget Architecture

Solution Approach

Instead of making hundreds of API calls to different services, let’s make a single network call to fire an event to a Topic (such as Kafka). Why not Queues or PubSub systems? Checkout the difference between the three with this amazing explanation by Nancy Agarwal 's post on Queues vs Topics vs PubSubs.

The originating service will fire a message to the Topic (or Kafka) and forget about acknowledgement, telling it to "replicate" the message and send to each subscriber. Each subscriber (or consuming service) can then pick up the messages on their own pace, consume the information and work independently, without relying on other Subscribers or Publisher in a tight fashion.

This way, each API call to the first service (Student Portal), will not wait or cause any delays in informing every single service, nor Student Portal will have the responsibility to register / change code whenever a new service comes up.

Whenever we have a new service, we just need to subscribe this service to the same Kafka Topic in just a Plug and Play kind of manner.

I keep writing stuff on backend engineering, system design and databases. To keep following, click on the ?? icon on my profile!

Conclusion

As we saw, there are various ways to communicate data over multiple microservices, it just needs the perspective through what you seem the system as. How heavy it is, how much data and how many load on the network. See you again in the next blog.!

If you liked this post, and learnt something new, don't forget to ?? Like and ?? Repost this article.