Backend System in Microservice Architecture: Where Does data store?
Last updated
Was this helpful?
Last updated
Was this helpful?
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.
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.
[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.
[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).
[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.
[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.
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.
The per service database and shared database can coexist.
[1] Bruce, Morgan, and Paulo A. Pereira. Microservices in action. Simon and Schuster, 2018. [2] [3] [4]
