Message As a Service - Service Bus

Synchronous Communication

When two components such as microservices are communicating with each other, the usual communication mechanism is the traditional, synchronous HTTP request, which consists of component A sending a request via HTTP and waiting for component B to respond.

The approach has a wide range of benefits, such as:

• Immediate response: the caller blocks until its request gets processed
• Immediate error feedback: both components can deal with failures once the failure happens
• No extra infrastructure: you need to implement the endpoints, auth, error handling, and so on, but you don't need to configure an external service or platform

The traditional approach has several benefits, but what happens if the component needs to perform a large number of operations? What if it doesn't need to wait until every integration with an external system finishes? What if you don't want the temporal coupling? What about cascading failures, when component A calls component B that calls component C and so on? What if you need an asynchronous communication style?

Asynchronous Messaging

That's when the asynchronous messaging concept comes into play. By using this approach, you can build asynchronous operations.

For instance, component A can send a message to a message broker, which can deliver it to the listeners that are interested in it. The message broker is a central component that receives all the incoming messages into queues or topics, and the listeners fetch these requests from the message broker.

This approach has a wide range of benefits as well, such as:

• Asynchronous operation: the component sending the request does not need to wait until it finishes
• Usually the message broker offers a lot of built-in features such as retry mechanisms and dead-letter queues
• Decoupling
• Resilience: the consumer can be down and the messages wait
• Load levelling: it can absorb traffic spikes

Service Bus on Azure

On Azure, one of the options for implementing this communication style is Service Bus. Azure Service Bus is a managed enterprise message broker with queues and publish-subscribe topics.

You can choose between queues and topics. Queues store messages in a queue until the receiving component is available to process them. It follows the competing consumers pattern, one message to one consumer. Topics support multiple subscriptions, so each topic subscription receives a copy of the message. On Azure, the Basic tier doesn't support topics.

Drawbacks to Consider

It is important to be aware of some drawbacks as well, such as:

• Eventual consistency: the data across services won't be in sync immediately
• Complexity
• Harder debugging and tracing
• Requires idempotent consumers

To conclude, it is important to know the communication styles and their benefits and drawbacks, so this knowledge can sharpen and guide our decisions instead of just doing things willy-nilly.