![]() ![]() But distributed data structures mean that you can't make a single ACID transaction across microservices. This would break the microservice lifecycle autonomy. If multiple services were accessing the same data, schema updates would require coordinated updates to all the services. Even when using ACID transactions within a microservice or Bounded Context, it is crucial to consider that the data owned by each microservice is private to that microservice and should only be accessed either synchronously through its API endpoints(REST, gRPC, SOAP, etc) or asynchronously via messaging(AMQP or similar).Įncapsulating the data ensures that the microservices are loosely coupled and can evolve independently of one another. However, data access becomes much more complicated when you move to a microservices architecture. This approach provides a way to easily write a query that combines data from multiple tables. It's like trying to use the same physical map for hiking a short trail, taking a day-long car trip, and learning geography.Ī monolithic application with typically a single relational database has two important benefits: ACID transactions and the SQL language, both working across all the tables and data related to your application. But the reality is you end up with huge tables that serve many different subsystems, and that include attributes and columns that aren't needed in most cases. ![]() The centralized database approach initially looks simpler and seems to enable reuse of entities in different subsystems to make everything consistent. In the microservices approach, each microservice owns its model/data. In the traditional approach, there's a single database shared across all services, typically in a tiered architecture. Data sovereignty comparison: monolithic database versus microservices This is often a normalized SQL database that's used for the whole application and all its internal subsystems, as shown in Figure 4-7.įigure 4-7. On the other hand, the traditional (monolithic data) approach used in many applications is to have a single centralized database or just a few databases. This point about the Bounded Context pattern is expanded in the next section. Each DDD Bounded Context correlates to one business microservice (one or several services). This principle is similar in Domain-driven design (DDD), where each Bounded Context or autonomous subsystem or service must own its domain model (data plus logic and behavior). Consider enterprise applications, where customer relationship management (CRM) applications, transactional purchase subsystems, and customer support subsystems each call on unique customer entity attributes and data, and where each employs a different Bounded Context (BC). ![]() This means that the conceptual model of the domain will differ between subsystems or microservices. Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. An important rule for microservices architecture is that each microservice must own its domain data and logic. ![]()
0 Comments
Leave a Reply. |