Backend System in Microservice Architecture: Where Does data store?

software development microservice design pattern

xiang753017 2022-06-23 14:55:06 ‧ 1308 瀏覽

分享至

Backend System in Microservice Architecture: Where Does data store?

At recent years, the Microservice architecture pattern widely applied in new systems. On the other side about old system, it also was transformed into Microservice architecture from monolithic architecture. The biggest reason why Ｍicroservice is popular is that the development and maintenance costs will significantly decrease in the long term.

[1] Microservice splits the monolithic system into many services by their domain and running on the container. That not only modularizes the program but also the service can retain their data that is the most different from SOA(Service-Oriented Architecture) Architecture.
GitBook Draft

SOA provides an interface for reusable components, as knowns as a modularized reusable module

So the data is the key difference from the SOA concept. However, there are two styles of how data do store. (1) Shared database. (2) Per database in Service.

Shared database

[2]Every Server shared the same database which is the meaning of a Shared Database. This style is a simple way like the SOA concept. But it has a big problem with single failure and does not fully have the advantage of Microservice.

This pattern is not only a single failure but also has a big problem with cloud deployment. When the service is stateful instead of stateless that implies a problem with how data do consistence.

So that the shared database is better to use in all accessed services are stateless.

Per database in Service

[2] Per database in service that means the service is stateful because of service owns their data. This style is more complicated than the shared database. It should dispose of the ACID issue, but the biggest advantage can avoid a single failure problem.

[4]ACID:

Atomicity: Atomicity guarantees that each transaction is treated as a single "unit", which either succeeds completely or fails completely.

Consistency: Consistency ensures that a transaction can only bring the database from one valid state to another, maintaining database invariants.

Isolation: Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially.

Durability: Durability guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure (e.g., power outage or crash).

How do dispose of the ACID problems if using the Per database in service? (Using Saga Pattern)

[2]The Saga Patten is a solution. The stateful service communicates with each other through the message queue that calls the broker. The broker should choose the mature queue like Rabbitmq, Kafuka... They can ensure the data will lose when the service does not pull off.

Choreography-based saga

Choreography-base means a function will split different services. All services communicate with each other.

Orchestration-based saga

Orchestration-based saga means split service by domain. A function stage will do all sequences stage completely and then pop out the result to the broker.

But the Saga still has a problem do not consider that its service has a chance to crash and recover. It will miss a command or action from the crash situation. So the Event Sourcing pattern has another pattern to figure out.

Event Sourcing pattern

[2]Every query in event sourcing is an event. All Events will be backed up by the event store to figure out the service crash problems that some events do not execute. Event-Store is the backup service that is stateful and has a database in self-service.

The dynamic diagram of Event Souring Pattern (below figure). There are two stages in the sequence diagram. First, All Consumers restart should check their task is completely done. Second, consumers listen to new events and do the new task.

Conclusion

In Microservice architecture, there are two situations. One is a stateless service that can use the shared database pattern. The second is a stateless service that should use Saga + Event Sourcing patterns to handle the ACID issues.