8 Fundamental Microservices Patterns and Concepts

In this article, we would discuss 7 key concepts in Microservices. We would also illustrate them with diagrams.

They are:

1. Database per Service
2. Shared database
3. Saga
4. API Composition
5. CQRS
6. Domain event
7. Event sourcing
8. Domain-Driven-Design

Each of these concepts is discussed in more details in their respective sections.

1. Database per Service

In this approach, each microservices persistent data is kept private to that service. And this data can only be accessed through an API provided by that service. This means that a services database is essentially  an integral part of that service and therefore cannot be accessed directly by other services.

The three ways to achieved a database-per-service pattern are:

Private tables-per-service: Here, each services owns a group of tables that must be accessed only by that service. This approach has the lowest overhead.

Schema-per-service: Schemas are created in the database where each service has its own schema. Schemas are private to each service.

Database server-per service: This is the last resort where each service has its own database server.

2. Shared database

In this pattern, we have different services accessing data from the same database. In some cases, it would require that the same permission level is provided for all the services. This pattern tends to be easier to implement. However, it tends to create a development and runtime coupling. This is in addition to other drawbacks.

3. Saga

So, what is a saga? Simply put, a saga is a sequence of local transactions. A saga would be necessary if you have a transaction that spans multiple services. It helps to maintain data consistency for distributed transactions.

More details available in the Saga section.

4. API Composition

The API composition provides a way to join data from multiple services. Assuming you implement database per service, then you have a query that needs data from different databases, then an API composer can be used.

This however requires an additional layer of abstraction receives the distributed query, splits it into different local queries, then receives and combines the results in-memory and returns it as a single result.

5. CQRS

CQRS stands for Command Query Responsibility Segregation.

As the name shows, we want to separate inbound requests into commands and queries. So we need to maintain a copy of the data in form of a ‘view database’ or materialized views. This would be a read-only replica that provides a response to the queries. So when a change is made to the database, an event is published that updates the view database.

6. Domain event

This is actually a concept that relates to CQRS. Domain events are events emitted by aggregates when they are either created or updated. These event can either be consumed by a services or used subscribed to by a view database a mentioned in case of CQRS.

So any state-changing operation that occurs in a services is emitted/published as an events

7. Event sourcing

This provides a way to persist the state of an entity (Order for example) as a sequence of state-changing events. So whenever, the state of the entity, changes, an event is published and added to a list of events or event store. This means that the the state of the entity at anytime could be recreated by replaying the events.

And since an event is atomic, we can be sure that consistency can be maintained in case of transactions.

8. Domain-Driven-Design(DDD)

This a concept in microservices where the focus of the design is on the core domain and the domain logic. We can think of it as Object Oriented Design applied to business model. However in DDD, instead of designing in terms of objects, we design in terms of domains (subject area on which the application is intended to apply)