Let's start with something simple to understand microservices design: what is microservices architecture? It is a set of small services, which will behave autonomously and independently. Each one should encompass a specific part of the business logic.

In more formal words we can define it as an architectural style for application development.

For example, if we have an application from a store, two possible services could be Order y Product. Each one will manage all the logic related to that part of the application.

And you will say, but what advantages does this architecture give me over monolithic architecture?

• Autonomous and independent services.
• Decentralization.
• Scalability.
• Flexibility in the face of possible changes.
• Isolation in case of failure.

In this article, we are going to mention five types of microservices design patterns, so that you can choose the one you think best suits your project.

Aggregator pattern

It implements a common management point between the different services, with the purpose of collecting information from them or implementing a specific functionality.

This pattern will be in charge of collecting information from each service, applying the required business logic and publishing it to the rest of the services, so that those that require it can consume it.

Advantages:

• Reduction of possible communication overhead between server - client.
• Centralization of business logic.
• Easy implementation.
• Provides single-access-point for services.

Event Sourcing

Communication between services is a major pillar of this architecture. To manage this we can apply the Event Sourcing. It will allow us to have a centralized point for the management and dissemination of all events sent between services. Each of them will send a series of events that will indicate the actions that are being carried out to later be stored in event store.

One possible implementation could be when the application will persist these events within the store. It will offer an API, which will be accessible to all services, and will be able to add or retrieve events that a service has issued.

On the other hand event store could behave as a message broker (this is perhaps the most common implementation), and all services that require it can subscribe to it.

Advantages:

• Persistence of events, being able to have a history of these.
• Possibility of implementing queries to determine the status of a service at any time.
• Prevents possible conflicts in concurrent systems.
• Weak coupling between services.

Command Query Responsibility Segregation (CQRS)

This pattern will be a good implementation when we have access to a single database. The application will be divided into two implementations:

• Commands: will handle all requests involving a request for a modification of the resource.
• QueriesThe following are handled, on the contrary, for all requests that consult information on one or more resources.

With this we get an abstraction of the data to be modified from the data to be read.

Advantages:

• Increased data availability.
• Get more flexible and easier to maintain systems.
• Separation of responsibilities in writing and reading.

Database per service

This pattern provides each microservice with its own database. It is usually the next step to follow when migrating from a monolith to a microservices architecture.

We will avoid a strong coupling between services and the data persistence layer. With this structure, the database will become part of the implementation of each service. It should not be accessible from other services, to get data between them we will use the pattern event-driven.

Advantages:

• Low coupling.
• Scalable application.
• High availability.
• Possibility of using different technologies within the same application, using the one required for each service.

Saga pattern

For this case we will manage the possible transactions between services using sagas.

But what is a saga? A saga is a sequence of operations that will update each service and publish a message or trigger the next action of the operation. Each operation will become part of a saga, This will ensure that all operations are completed and that each transaction is executed concurrently.

We will use this pattern to maintain data consistency between services.

For this pattern we have two principles:

1. Choreography

Each transaction will publish events which trigger other transactions in other services.

2. Orchestration

In this case we will have an orchestrator that will be in charge of managing which transaction will be executed in which service.

Advantages:

• It enables the management of transactions based on messages and thus having a weak coupling.
• Consistency between services.
• Good use in transactions with little complexity and few steps.

Conclusions

In this short article we have exposed some of the main solutions that we can apply in our projects to make them more consistent, flexible and accessible, both for the case of migration from a monolithic architecture, as well as for a new project.

There is no reason to implement each of them, since the main thing is to look at the needs that our application will have, and our own criteria.

Using design patterns will always be a solid base to start from, but then the real art will be created by us.