✍️
ZiXiang-Blog
  • Jerry Wang Blog
  • 使用 TorchServe 部署 Model
  • How do AppRTC work in WebRTC mechanism ?
  • [系統設計]- 容易產生設計盲點
  • Golang
    • [Golang] Goroutine Concurrency多執行緒淺談
    • [Golang]: 進階用法
    • Golang go mod 入門
    • [Golang] 讓 Goroutine Debug 變得更簡單
  • Security
    • HTTP Token 使用方式: Basic Token v.s Bearer Token
    • 從 RFC 規格書觀點解析 OAuth 2.0
    • 區塊鏈物聯網架構 解決哪些安全性議題?
  • Broker
    • [深入淺出MQTT]: v3.1.1與v5 的差異
    • Broker 到底是什麼?
  • patterns
    • Patterns for Organizing Domain Logic
    • Domain Model: 從無到有規劃新的服務
    • 淺談CQRS
    • Backend System in Microservice Architecture: Where Does data store?
    • Ambassador pattern with Shared Database Pattern
    • Microservice Pattern 犧牲了什麼?
  • K8s
    • 分散式系統: 現代軟體架構與設計考量
    • Kubernetes 超入門
    • Kubernetes 架構
    • K8s 在 DevOps 中的作用
  • Database
    • Relation Database Index Overview
    • Draft: RDBMS(MySQL) v.s NoSQL (Monogo)
    • [淺談]- How Do RDBMS Thread work ?
    • [淺談]-NoSQL資料庫怎麼選?
    • How do pick the database more correctly?
    • Draft: 關聯式資料庫需要知道的幾件事
  • HTTP
    • Overview The WebSocket Mechanism
Powered by GitBook
On this page
  • Shared database
  • Per database in Service
  • Conclusion
  • Reference

Was this helpful?

  1. patterns

Backend System in Microservice Architecture: Where Does data store?

Previous淺談CQRSNextAmbassador pattern with Shared Database Pattern

Last updated 11 months ago

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 Microservice 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.

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:

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

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

  3. 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.

  4. 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.

The per service database and shared database can coexist.

Reference

[1] Bruce, Morgan, and Paulo A. Pereira. Microservices in action. Simon and Schuster, 2018. [2] [3] [4]

https://microservices.io/patterns/microservices.html
https://www.ibm.com/cloud/learn/soa
https://en.wikipedia.org/wiki/ACID