Synchronous Request/Reply is Bad

In previous posts, I have stated that synchronous request/reply is a bad idea between services, but I think it warrants its own post to discuss.

Synchronous request/reply is a message exchange pattern where a request message is sent by a service, where the sending thread is then suspended until the response is received.

So why is synchronous request/reply so bad? One reason relates to performance. Consider a situation where you have many services communicating in a complex interaction.

The first service makes a request to the second, which then makes a request to the third, which then makes a request back to the first and so on. The thread that sent the original request is still waiting for its response.

When you have many requests and responses going over many network boundaries, the requesting thread will be waiting a long time. It may in fact wait forever. One tenet of SOA is that services are autonomous. There is no requirement for them to be available all the time.

While it is waiting, the requesting thread is tied up unable to be used for any other purpose. Effectively what results is a whole bunch of threads across a number of services sitting around waiting for responses.

The performance of your entire service ecosystem grinds to a halt. Meanwhile the CPU utilisation on each of the machines is nearly zero. No work is being done; everyone is just waiting for everyone else.

Obviously this result is unacceptable. I'll cover another key reason why synchronous request/reply is a bad idea between services in my next post.