Communication in Microservices Architecture
Anyone interested in cloud native, software architecture or who hurted from monolithic applications knows that the best solution of escaping monolith hell is microservice architecture. As Fred Brooks says, of course there is “No Silver Bullet” for software. But as many of us who had worked with monoliths know that monoliths have many problems for big software projects enough to be a hell. The truth, we cannot deny is that microservices can solve most problems caused by monolithic arch. If you decided to apply microservices architecture for your project, you have to be very careful and produce some constraints better than monoliths like response time, error rates, high availability etc. otherwise there is no meaning to applying microservices architecture.
Every architectural decision regarding the application affects the product and/or the end user. This affects brand value and usability. Brand value means prestige. Microservices arch. has many benefits and drawbacks, if you want to take advantage of these benefits you should play the game according to the rules. If you don’t, in time, your services will be come distributed monolith and you will have both monolith and microservices drawbacks. This means while escape from hell, you will find your project in distributed hell.
We realized that applying the microservices architecture was not enough. So what should we do to take advantage of microservices architecture? Looking at events, structures, transactions and especially communication from a micro-services perspective is different from traditional approaches. The focused and main idea should be to solve problems before they occur. We will consider this issue from the communication aspect. There will be couple of humbly tips and tricks about communication in microservices architecture.
In microservices architecture, communication takes place in two ways. These are synchronous and asynchronous communication. When and how do we use these methods?
Sync Communication:
It is a communication method that takes place with instant, real time and direct api call, its occurs with protocols such as http, tcp/ip or rpc etc. This method should generally be used in situations where the end user is interacting and / or requires an instant response. This situation can be used at the stage of communicating with both internal and external systems. It is a costly communication method and should be used carefully. It may affect resources and scalability.
Async Communication:
It is a form of non-instant and non-real time communication. APIs often communicate with message queues or events. This communication method forms the basis of loosely coupled architecture approaches. It should be used in situations that do not affect the end user or do not require instant answers. It is an excellent method for batch processing. It also benefits for resource utilization and scalability.
Tips: In microservices architecture, it should be checked if possible to performing asynchronously while performing a transaction. If possible, it should be do as asynchronous.
The application of these methods, directly or indirectly affects the results. Let’s take a closer look at these results and architectural actors and see their relationships with each other.
Response Time:
Response time is a very important phenomenon. In fact, it can affect the prestige of the product and the brand. The response time of a quality service should be very low in milliseconds. In order for the response time to be healthy and low, we need to produce strategy on a case-by-case basis. Let’s go to these situations through a few scenarios.
Regardless of the external or internal system, when we return just Http OK, id or something similar which is we can provide in low time, we can leave the request in the message queue after we receive the request so that long processes do not take time.
Another important point is unnecessary database operations and external api calls that occur during a transaction. This is an issue that affects response time and needs to be very careful and unnecessary procedures should be avoided.
Error Rate:
Error rate is a very important metric and actor in microservices architecture. It affects the communication between our services directly or indirectly. The error rate can vary a lot depending on the domain and business, as well as telling us a lot in terms of architecture, communication, service health, and scalability. Correctly correlates with monitoring and RPM. According to the error rate, we can understand that a service should be performed by synchronous or asynchronous communication. Another benefit is that, due to unexpected errors, we can interrupt requests that engage in communication, and contribute to response time and rpm.
Throughput (RPM):
Throughput is measured as Requests Per Minute. RPM and Throughput supports each other in terms of knowledge. It means how many request handle your api in time. If Api RPM is high, the api is healthy and produces good throughput under load. These are very important metrics and actors for communication in microservices and they related with everything about apis. If rpms and throughputs are low, there could be something wrong in api.
Circuit Breaking and Retry Mechanism:
Suppose that we somehow had to use the synchronous communication method. In such cases, we need to use a circuit breaker or retryer on our request mechanism. With examples we can explain this situation as follows. Services with a long response time also extend the response time of your service. This affects your communication badly. In such cases, the maximum waiting time should be determined and if this time is exceeded, the retry mechanism should be used. When using the retry mechanism, we should be careful to create a dynamic mechanism. In this way, we can both carry out the communication in a healthy way and we can make our transactions efficiently.
Another situation is that the service that we send the request may not be up or cannot respond to us at that moment. In this case, we should check whether our requests can be forwarded by using a circuit breaker before the loaded requests we send.
Caching:
Cache is very important mechanism and actor in communication between microservices. Cache directly affects communication. There are situations when cache should and should not be used. If the cache is used with the right approach, it becomes an excellent actor for communication between APIs and affects the end user in positive way.
When should not use? : If data is updated instantly and frequently depending on the domain and business, cache should not be used. In this case, cache usage is no more than just showing incorrect data.
When should use? : Cache can be used if data does not change instantly. There are several different types of cache usage. If api is single source of truth, cache mechanism should use with eviction and update cache itself. If api is just has a client role then cache should use with time to live(ttl). Another important case in cache usage is that using cache with in memory or with nosql. It’s about data size and this matter is very important for api source usage. If the data size is small, we can keep the data in memory cache. In this case, we should pay attention to this; If we keep everything in memory, resource usage may be uncontrollable. Another method is to use nosql. It is relatively more controllable. The point to be noted here is that the same nosql source serves more than enough api. Nosql structures that serve more than their capacity cease to be useful over time.
Utilities And Results
Monitoring:
Monitoring has a very important place in microservices architecture. Monitoring should be the method that we developers use the most, so that we can analyze the availability, communication and instant behaviors of the services. As I mentioned before, we must detect and solve a problem before it occurs. Thus, we can monitor the system and see the outputs of the communication decisions that we made. Monitoring provides us with reference data for other actors, methods and results in the system.
Scalability:
Scalability is a result of what kind of communication method we use and how the transactions are performed. Before we scale a service, improvements we can make should be reviewed and scalability as a last resort should be applied.
High Availability:
One of the primary objectives of the micro services architecture is high availability. We can increase the high availability of our system with the correct use of resources and a correct communication method.high availability is a result of communication method, throughputs, cache mechanism and relation between them. These approaches and actors directly affects the high availability. We must properly set up and manage our structures for a highly available system.
As a result, we learned how important communication is in micro services architecture. The results and effects of the communication method are vital for our system. For this reason, every communication method established and every action taken should carefully implemented.
