7 Database Patterns for Microservices – Explained With Diagrams

We would learn about 7 database patterns for Microservices. The include:

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


1. Database per Service

In this pattern, the microservice’s persistent data are kept private to that service and is can only be accessed through its API. A transaction by a service involves only it’s database.

Therefore, the database for that service is essentially part of the implementation of that microservice and thus cannot be accessed by external services.

Ways to keep a microservice’s data private includes:

  • Private-tables-per-service
  • Schema-per-service
  • Database-server-per-service

Benefits of Database-per-service

  • Ensures loose-coupling between the services
  • Different service can used a suitable database based on it’s needs

Some Challenges of Database-per-service

  • Some complexity due to creating transactions that span multiple services
  • Several join queries has to be written
  • Hard to cordinate multiple SQL and NoSQL databases


2. Shared database

The shared-database pattern  allows different services to access the same database. The approach is to use a single database that is shared by multiple services. Thus each service can freely access the data that is owned by other services.

Benefits of Shared Database

  • Use of ACID transaction to enforce consistency is very clear and straighforward
  • It is easier to implement a single database

Challenges of Shared Database

  • Just one database could not fill the data requirements of all the services
  • Additional coordination during development time between different teams working on different services as they need to access the same data storage
  • Runtime couple could impede performance


3. Saga 

A saga in defined as as sequence of local transactions. In this case, these are transactions that span multiple services. In  a saga, each local transaction executes on a database, then publishes a message/event that triggers the next local transaction in the sequence.

If however, one transaction fails in the saga, then a series of  compensating transactions in executed to rollback the changes made by the preceding transactions. This is illustrated in the figure below. The Patient service holds information about patients admission into a hospital while the Patient service holds the patient’s details.

How Saga Works
How Saga Works

Benefits of Saga

It allows an application to maintain consistency in its data across multiple services without having to use distributed transactions


Challenges of Saga

Has a complex programming model



4. API Composition

This is a way to implement queries that access data across multiple services.

The API Composition is achieved by creating an API Composer (which could be another service) that invokes that services that owns the data. Then it performs joins of the results in-memory. This is illustrated below.

API Composer
API Composer


Benefits of API Composer

Straightforward way of querying data across services


Challenges of API Composer

Some queries may perform inefficiently due to joining large resultsets.



CQRS stands for Command Query Responsibility Segregation.

In this pattern, we define a view database. This is a read-only copy of the database that is made to support the particular query. So the application maintains this copy up to date  by subscribing to the domain events emitted by the service that owns the data.

Command Query REquest Segregation
Command Query Request Segregation

Benefits of CQRS

  • Has support for multiple denormalized views which has good performance and are scalable as well
  • Separation of Concerns is improved due to simpler command and query models
  • Can be used in an event sourced design

Challenges of CQRS

  • Complexity is increased
  • Possible code duplication


6. Domain event

In this pattern, business logic is organized as a collection of domain-driven-design(ddd) modules. These module emit domain events anytime they are created or updated. The service then published these events so that the can be consumed by other microservices.

Benefits and challenges are similar to Command Query Request Segregation


7. Event sourcing

In this pattern, the state of the business entity such as Patient or Admission  is persisted as a sequence of state-changing events.

Each time the state of a business object changes, a new event is added to the queue of events. In this way atomicity can be guaranteed. The figure below illustrates Event sourcing

Benefits of Event Sourcing

  • It ensures that events are reliably published each time there is a state change
  • It avoids object-relational inefficiencies since events rather than domains are persisted
  • It provides an audit log of changes made to business entities
  • Allows for implementation of temporal queries
  • Supports loose-coupling of business entities

Challenges of Event Sourcing

  • It is an unfamiliar programming model and therefore has some learning curve
  • Event stores could be inherently difficult to query
User Avatar


Kindson Munonye is currently completing his doctoral program in Software Engineering in Budapest University of Technology and Economics

View all posts by kindsonthegenius →

Leave a Reply

Your email address will not be published. Required fields are marked *