Microservices. Data management between services

What is a microservice?

With a monolithic architecture, this is a way to build servers in a monolithic server.

monoliticServer

All the code needed to implement our application inside of one single code base and we deploy that code base as one discrete unit.

A monolith contains

1
Routing
2
Middlewares
3
Business Logic
4
Database access

to implement all features of our app

Microservice architecture.

microservices

With this microservice architecture, we’ve now split off all these different features and wrap them up inside of their own little personalized services.

A single microservice contains

1
Routing
2
Middlewares
3
Business Logic
4
Database access

to implement one feature of our app

Data management between services

This is the big problem of microservices. When we say data management, we are talking about the way in which we store data inside of a service and how we comunicate that data between different services.

database

Whenever we are making use of microservices, we are going to create a separate database for each service.

neverOtherDatabase

Why Database-Per-Service

We want each service to run independently of other services
Database schema/structure might change unexpectedly
Some services might function more efficiently with different types of DB’s (sql vs nosql)

databasemonolitic

If we want to to actually show information about those products, we probably have to do a query over to the products collection as well. We’re accessing these three different sources of information to implement this one single feature and inside of a monolithic server.

DATABASE MS

How could we somehow get information required to implement Service D feature without reaching into these databases?

We don’t allow these services to interact with each other’s databases. That is why data management between services can be really, really challenging.

betweenServices

Sync
Service communicate with each other using direct request
Async
Service communicate with each other using events

Microservices Sync Communication

Conceptually easy to understand
Service D won’t need a database
Introduces a dependency between services
If any inter-service request fails, the overall request fails
The entire request is only as fast as the slowest request
Can easy introduce webs of requests

In Sync Communication there are some upsides but there are a lot of gigantic operational downsides as well.

Microservices Async Communication

First way

EventBus1 EventBus4

Conceptually not easy to understand
Service D won’t need a database
Introduces a dependency between services
If any inter-service request fails, the overall request fails
The entire request is only as fast as the slowest request
Can easy introduce webs of requests

Second way (crazy way of storing data)

service

database

Create a product

Create a user

Order a product

Service D has zero dependencies on others services
Service D will be extremely fast
Data duplication.
Hard to understand

Soon I will create a post where we will see how to create microservices with NodeJS and React. We will go this second way to create the microservices and store the information. This is a topic we haven’t seen in Google Cloud Microservices post.

0 replies

Want to join the discussion?
Feel free to contribute!