Synchronous Request/Reply is Bad (continued...)

In my last post, I demonstrated that synchronous request/reply is a bad design choice for performance reasons.

The other reason to avoid synchronous request/reply goes to reliability. A requesting service invoking another service with synchronous request/reply will likely fall over if the receiving service is unavailable for some reason. You could have a situation where when a critical service goes down, every other service goes down.

Yes, you could build compensating logic into your service to handle retries so a failed request doesn't cause the requesting service to fail. But that is a lot of work you would have to do yourself. When using an asynchronous approach, the messaging infrastructure will handle retries for you.

Moreover, asynchronous messaging infrastructure will provide transactional guaranteed once only message delivery. With synchronous request/reply you must make sure your message is handled idepotently (meaning that if it is received multiple times there are no side effects) as well. Retries may result in the same message being delivered multiple times. Again, this is more work for you. All the while, the sending service has a thread tied up awaiting the response.

Note that synchronous request/reply is no sin inside the service boundary. It is quite acceptable and often necessary to leverage synchronous request/reply inside the service boundary, such as between the user interface and application tiers. Here, there is no domino effect that will bring down your entire enterprise. The effect of a system going down is confined to the service in which it occurs.

But between services if you require request/reply, use the asynchonous variety. I'll cover asynchronous request/reply in my next post.