Microservices Data Design Patterns

Database per service

Benefits of having a database per service

  • Loosely coupled
  • Free to choose database types such as RDBMS like MySQL, wide-column databases like Cassandra, document databases like MongoDB, Key-Value stores like Redis, and graph databases like Neo4J.

If you are using an RDMS then the options are:

  • Private tables per service —There is a set of tables owned by each service that must only be accessed by that service.
  • Schema per service — Every service has a database schema that is private to it.
  • Database server per service — Each service has its own database server.

Challenges of having a database per service

  1. Queries that need to join over multiple databases — The following data patterns will help us overcome this challenge.
  • Event Sourcing
  • API Composition
  • Command Query Responsibility Segregation (CQRS)

Now let’s examine the different data patterns.

Event Sourcing

Benefits of event sourcing

  1. Using it solves one of the key challenges of event-driven architecture and makes it possible to reliably publish events when the state changes.
  2. It mostly avoids object-relational impedance mismatch problems since it persists events rather than domain objects.
  3. It provides a 100% reliable audit log of all changes made to an entity.
  4. It allows for the implementation of temporal queries that determine the state of an entity at any point in time.
  5. Business logic based on event sourcing involves loosely coupled entities that exchange events. This makes migrating from a monolithic application to a microservice architecture a lot easier.

Drawbacks of event sourcing

  1. There is a learning curve because it is an unfamiliar style of programming.
  2. Querying the event store is difficult since it requires a typical query to reconstruct entities states. Inefficient and complex queries are likely to result. Therefore, the application must implement queries using Command Query Responsibility Segregation (CQRS). In turn, this means that applications must handle eventually consistent data.

API Composition

Benefits of API Composition

  1. This is a convenient way to query data in a microservice architecture.

Drawbacks of API Composition

  1. Occasionally, queries would result in inefficient, in-memory joins of large datasets.

Command Query Responsibility Segregation (CQRS)

  1. Data scattered across multiple services is retrieved using the API composition pattern, resulting in expensive and inefficient in-memory joining.
  2. Data is stored in a format or in a database that does not efficiently support the required query by the service that owns the data.
  3. Separating concerns means that the service that owns the data shouldn’t be responsible for implementing query operations.

All three problems can be solved by using the CQRS pattern.

Benefits of CQRS

  1. Enable the efficient implementation of queries in a microservice architecture — If you use the API composition pattern to implement queries, you may experience expensive, inefficient in-memory joins of large datasets. For these queries, using a CQRS view that pre-joins data from two or more services are more efficient.
  2. Enables the efficient implementation of diverse queries — It is often difficult to support all queries using a single persistent data model. In CQRS, one or more views are defined that efficiently implement specific queries, eliminating the limitation of a single datastore.
  3. Makes querying possible in an event sourcing-based application — CQRS also overcomes an important limitation of event sourcing. An event store only supports queries based on primary keys. The CQRS pattern addresses this limitation by defining one or more views of the aggregates that are kept up-to-date by subscribing to the streams of events that are published by event-sourcing aggregates.
  4. Improves separation of concerns — Domain models and persistent data models do not support both commands and queries. CQRS separates the command and query sides of the service into separate code modules and database schema.

Drawbacks of CQRS

  1. More complex architecture —In order to update and query views, developers need to write query-side services. Different types of databases might be used by an application, which adds to the complexity for both developers and DevOps.
  2. Dealing with the replication lag — Between when an event is published from the command side and when it is processed by the query side and when the view is updated, there is a delay.

Saga Pattern

Coordinating Sagas

There are a couple of ways to structure a saga’s coordination logic:

Benefits of Choreography based sagas

  1. Simplicity — When business objects are created, updated, or deleted, services publish events.
  2. Loose coupling — Events are subscribed to by participants who are not aware of one another.

Drawbacks of Choreography based sagas

  1. More difficult to understand — The choreography distributes the implementation of the saga among the services.
  2. Cyclic dependencies between the services — The saga participants subscribe to each other’s events, which often creates cyclic dependencies.
  3. Risk of tight coupling — Participants in the saga must subscribe to all events that affect them.

Benefits of Orchestration based sagas

  1. Simpler dependencies — Cyclic dependencies are not introduced.
  2. Less coupling — Services implement APIs that are called by the orchestrator, so it does not need to know about events published by saga participants.
  3. Improves separation of concerns and simplifies the business logic — In the saga orchestrator, saga coordination logic is localized. Domain objects have no knowledge of the sagas in which they are involved.

Drawbacks of Orchestration based sagas

  1. The risk of centralizing too much business logic in the orchestrator — If you design orchestrators that are solely responsible for sequencing and don’t contain any other business logic, you can avoid this problem.

References

--

--

--

“Walking on water and developing software from a specification are easy if both are frozen”

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Jitter #5 | FX @ ttributes

How To Make An App Like Uber

HashiCorp Simple Policy

Crodo.io: news

My journey in DLithe Bootcamp

Recycler View Using kotlin with click listener

AWS EKS: Calico for Windows networking

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Neeraj Kushwaha

Neeraj Kushwaha

“Walking on water and developing software from a specification are easy if both are frozen”

More from Medium

Microservices Communication Design Patterns

Microservices

Securing Microservices with OAuth2

Microservices: The Saga Pattern