When you build an application, the most important decision you need to make is what type of architecture are you building? Different architecture styles are adopted for different purposes such as traditional, monoliths N-tier architecture, event-driven architecture, service-oriented architecture, and microservices architecture. Let us take a look at the microservices architecture along with the message broker service at a high level.

Today, microservices are one of the most popular architectural styles for building applications – that are robust, flexible, highly scalable, and independently deployable. Microservice architecture is distributed and loosely coupled, so one component’s failure will not crack or crash the whole application. This also allows independent components to collaborate and communicate with well-defined APIs.  Moreover, you can easily scale particular functional areas that need more processing power.

Image ref: https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

In the past few years, microservices architecture has gained a great momentum. According to O’Reilly survey on Microservices Adoption in 2020, slightly more than one-third of respondents say their organizations have been using microservices for between 1 and 3 years (as shown in the below image).

Image source: https://www.oreilly.com/radar/microservices-adoption-in-2020/

In the same survey, a majority of respondents (55%) say their organization’s use of microservices has been either a “complete success” (close to 9%) or “mostly successful”.

Image source: https://www.oreilly.com/radar/microservices-adoption-in-2020/

So, the adoption of Microservices is on the upward trajectory.

However, in microservices architecture-based applications, many critical components come into play for the smooth operation of the app. One of them is how different components communicate with each other. When different small services interact with each other to complete a single business activity, establishing robust communication can be challenging, primarily to get optimal performance.

Let’s look at the various messaging options available with Microsoft at a high-level and dig deeper into one of them in using a typical scenario.

Use Case Scenario

Imagine we are building a digital commerce solution where we need a highly scalable and resilient architecture for online order processing. Here, the traditional monolithic approach might not be beneficial due to the complexity and dependencies of the various components involved. Tight coupling would create a lot of challenges for building a scalable solution.  

In a microservice architecture, the approach is different. Usually more than one services are involved for processing a request. For instance, placing an order will involve a combination of multiple orchestrated service call in a reliable and failsafe manner. It may involve reading the cart, applicable offers, interacting with payment gateways, validating the customer address, validating and/or updating the product inventory, and once everything is successfully complete, sending the order confirmation to the customer.

So, here we see the architecture must handle multiple service requests in a transparent manner from the user point of view. And they need to collaborate seamlessly. In a simplified version, the order placement solution example could use the following microservices for different events (order placement, product availability, payment, and confirmation):

• Process Cart – validate items in cart and/or apply offers.
• Order API – placing the order.
• Customer API – validate address & credit card details.
• Product availability API – Responsible for viewing product availability in the inventory.
• Payment API – For interacting with payment gateways
• Notification API – For sending confirmation and notifications

For the sequencing of these microservices and guaranteed delivery, an accurate inter-service communication protocol must happen. But the question is how do these services in a microservice architecture communicate with each other?

Azure Messaging Services                   

Azure provides different asynchronous messaging options to help deliver events or messages in an micro-service based architecture as follows:

• Azure Service Bus— a fully managed enterprise message broker with message queues and publish-subscribe topics
• Event Grid— an ‘event’ing backplane that enables event-driven, reactive programming.
• Event Hubs— a big data streaming platform and event ingestion service.

Microsoft Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics. Along with decoupling the various components as well as internal & external dependencies, service bus also provides the following benefits:

• Load-balancing work across competing workers
• Safely routing and transferring data and control across service and application boundaries
• Coordinating transactional work that requires a high degree of reliability & resiliency

There are other numerous other advanced features such as processing transactions, message sessions, Autoforwarding, Scheduled delivery, Message deferral, batching etc. More details can be found here.

Efficient, resilient & reliable inter-service communication is one of the important attributes required in a microservice-based architecture. Using the right messaging options for the right job is the key here.