Inter service communication: request/response

Over the next few weeks I will cover a number of different ways to services can communicate with each other. First out is the classical request/response.

It should not be a surprise to anybody that this communication strategy involves one party (typically called the client) issue a request to the other party (server) and then waiting for a response from the server.

The obvious benefit of this pattern is that it is easy to understand, easy to implement and means the client and server are synchronized by the communication. This means that it is easy for the client to detect when the server is not working well as there would be a number of failures issuing the requests.

On the other hand if there is a significant amount of work that needs to be completed in order to create the response then resources related to the actual transport will become a bottleneck. Tis problem can be worked around by issuing separate requests to start work and monitor work for completion but this also means that you need to poll for completion.

When you need to add a new client to an existing server you can easily do so as the server does not need to know about the clients. But on the other hand if one client suddenly needs to send the same data to an additional server the client needs to change.

Next week I will talk about message bus communication.

No comments:

Post a Comment