In this blog, I will be talking about the microservice architecture commonly used in the industry and why many developers prefer this architectural type.

What is a microservices architecture?

This is an architectural style that structures an application as a collection of independently deployable services that are also loosely coupled. And each service will only be doing a specific job.

A single service should be:

Split based on business functionalities.
For one specific job.
Self-contained and independent.
Loosely coupled.

Example for servicers

In the above example, the application is divided into four services based on specific business functionalities. While each of these services is self-contained and independent, they may need to interact and communicate with each other to perform certain tasks. For instance, the checkout service might need to communicate with the shopping cart service to retrieve the items that the user has added to their cart. In the next section, we will explore the various methods and protocols used for communication between microservices.

Communication between services.

In a complex software architecture, services often need to collaborate and interact with each other to provide a seamless and integrated experience to users. For instance, the checkout service may require the assistance of the shopping cart service to retrieve the list of items that the user has added to their cart. Additionally, the checkout service may need to rely on another service, such as payment, to process the payment transaction. These interactions between services are essential to ensuring that the overall system works smoothly and efficiently and that end-users can accomplish their desired tasks without any hassle.

In a monolithic architecture, method calls are typically used to handle communication between different parts of the application. However, in a microservices architecture, each service is isolated and self-contained, which means that a different approach is needed for communication between services.

When communicating with internal services in a microservices architecture, there are two key factors to consider: the communication protocol and the receiver. These factors are critical to ensuring that services can interact with each other efficiently and effectively, which is essential for the overall success of the system. In the next section, we will delve into the different communication protocols used in a microservices architecture.

Protocol.

There are mainly two types of protocols that have been used for communication in microservices.

Asynchronous protocol: In this protocol, the sender doesn't wait for an immediate response back from the receiver it will continue its work while waiting for a response back from the receiver. One common way to implement asynchronous communication in microservices is through a message broker or service bus.
Synchronous protocol: The Sender will wait for a response from the receiver before continuing with its processing. This protocol type is often implemented with HTTP or HTTPS.

We will dig deep into how the asynchronous protocol is being implemented since this has been used more often in the industry.

Asynchronous protocol

In this protocol, the sender service will send the massage to the massage broker, which will store the message in a queue and send it to the receiver when it becomes available. This approach helps the services be independent of each other.

In the given example, the shipment handling service would send a message to the message broker, indicating that the shipment is ready for delivery. This message could potentially be in the form of an event and would contain relevant information such as the shipment ID, delivery address, and other pertinent details.

Assuming that the notification service has subscribed to this type of message or event, it would receive this information from the message broker as soon as it becomes available. Based on the contents of the message, the notification service could then take appropriate action, such as sending a notification to the customer to inform them that their shipment is on its way.

Furthermore, the notification service might have an event that takes user details as input, such as the user’s name and contact information. This information could be used to personalize the notification and ensure that it is delivered to the correct recipient. By binding data with events and using an asynchronous protocol, the shipment handling service and the notification service can work together seamlessly to provide a better experience for customers.

In some cases, we can make services talk to each other directly using an asynchronous protocol as well.

This protocol is often used in event-driven architecture.

Receiver.

There are two types of receivers as well.

Single receiver: Each request must be processed by exactly one service.
Multiple receivers: Each request can be processed by zero to multiple receivers.

Usually, a combination of these communication styles is used to communicate between microservices.

Benefits of using a microservices architecture.

Scalability: gives the flexibility to scale a single service independently depending on the requirement, without affecting other services.
Resilience: each service is isolated and can be designed to handle failures independently. This means that if one service fails, it does not bring down the entire system.
Flexibility: different teams can work on different services without interfering with each other.
Freedom to select the tech stack: Each service can be developed in a tech stack that suits the task the best.

Challengers of using a microservices architecture.

Complexity: when the number of services increases developers must manage how they interact with each other. Which can be challenging as the system grows.
Managing the network latency: since sometimes the servicers have to talk with each other, there might be network latency. If this isn’t managed properly.
Deployment complexity: With many independently deployable services, deployment becomes more complex. Each service must be deployed and managed separately, which can be time-consuming and error-prone.
Distributed transactions: Handling transactions that span multiple services can be challenging in a microservices architecture. Developers must ensure that transactions are properly managed to maintain data consistency.

Conclusion.

Despite the challenges that come with it, the microservices architecture pattern continues to be one of the most popular choices for large-scale industrial software systems. However, it is crucial to carefully consider the advantages and disadvantages before deciding whether to adopt this approach. By carefully weighing the pros and cons, organizations can make an informed decision that aligns with their business needs and goals. Ultimately, the success of any architectural decision relies on careful planning, execution, and ongoing evaluation to ensure that it continues to meet the evolving needs of the business and its customers.

An introduction to microservices architecture: what it is and why it matters

Table of contents