In the distributed systems, each subsystem is running on several different machines, and each service is a component or process of an enterprise application. that means these services at the multiple machines must handle requests from the clients of this enterprise application. sometimes all these services collaborate to handle those requests. so all services interact with each other. in case of the monolithic application, all components are the part of the same application and run on the same machine. so, monolithic application doesn’t require this complexity in interaction between services.
so we can classify this communications into two approaches like the following:
- Synchronous communication style.
- Asynchronous communication style.
Synchronous communication style:
in this communication style, the client service expects a response within time and wait for a response by blocking the request. this style can be used by simple using http protocol usually via rest. it is the simplest possible solution for synchronous communication to interact with services. the client can make a rest call to interact with other services. the client sends a request to the server and waits for a response from the service.
the synchronous communication approach does have some drawbacks, such as timeouts and strong coupling. but we can avoid coupling problem by using circuit breaker pattern.
we can use GRPC instead of rest.
this style good in some situations like if we need to pay order before we receive success page so order service must wait payment service until receive response from it to continue the order life cycle.
this style have the following tradeoffs:
1- couple between services.
2- block requests cause latency between services.
Asynchronous communication style:
in this communication style, the client service doesn’t wait for the response coming from another service. the client doesn’t block request while it is waiting for a response from the server. this type of communications is possible by using lightweight messaging brokers. the message producer service doesn’t wait for a response. it just generates a message and sends message to the broker, it waits for the only acknowledgement from the message broker to know the message has been received by a message broker or not.
there are various tools to support lightweight messaging, you just choose one of the following message brokers:
- RabbitMQ
- Apache Kafka
- ActiveMQ
lets take real use case for this communication style, if user placed order, user should receive confirmation email and sms, so order service will push 2 message to queue one for email service and second for sms service, once order service received acknowledge from the queue it will continue executing this request and the other service will receive this messages and handle this messages eventually. if sms and email service are down, all messages exist in queue.
Top comments (0)