Скачать или смотреть Ensuring State Consistency in Microservices: A Deep Dive into Shared Services

Discover how to maintain state consistency across microservices with effective design approaches while adhering to domain constraints and preventing code duplication.
---
This video is based on the question https://stackoverflow.com/q/71570423/ asked by the user 'recons' ( https://stackoverflow.com/u/18540180/ ) and on the answer https://stackoverflow.com/a/71575983/ provided by the user 'AndrewR' ( https://stackoverflow.com/u/6997699/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: Ensure state consistency by introducing a shared microservice?

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/l...
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license.

If anything seems off to you, please feel free to write me at vlogize [AT] gmail [DOT] com.
---
Ensuring State Consistency in Microservices: A Deep Dive into Shared Services

In the complex world of microservices architecture, ensuring state consistency across different entities can pose significant challenges. When dealing with multiple microservices that handle distinct aggregate roots, like Report and Inspection, this concern becomes even more pressing. In this guide, we will explore a situation where you need to fill out custom forms during the lifecycle of these entities while maintaining strict domain constraints.

The Challenge at Hand

You are tasked with implementing a feature that allows users to fill out dynamic forms which are essential to two entities, namely Report and Inspection. Here are the key characteristics of each entity:

Report: Contains an ID and a status (which can be opened, in-progress, processed, or closed) along with follow-up and investigation custom form answers.

Inspection: Comprises an ID and form answers.

Key Domain Constraints

In addition to the requirement of form creation, you also have to contend with specific business rules that must not be violated during the process:

Reports cannot change follow-ups if they are marked as processed or closed, unless modified by certain users.

Investigation forms can be filled only when the report status is processed.

Forms should have a consistent structure across both entities while preventing instances of the wrong form being filled in the incorrect context.

Solution Approaches

After outlining the challenges, it's time to consider potential solutions and weigh their pros and cons.

Approach # 1: Separate Form Entities in Each Service

One way to tackle this problem is to introduce a form entity within each service to store answers related to reports and inspections directly.

Pros:

State Consistency: Since forms and answers are checked within the same aggregate, you can more easily enforce the domain constraints and ensure correct state transitions.

Cons:

Code Duplication: With separate form implementations, you may see repeated code across services concerning validation checks and entity structures.

Change Management: If a new field type is introduced, you will need to update multiple services, leading to potential oversight and increased maintenance overhead.

Approach # 2: Centralized Form Service

An alternative strategy is to implement a new, dedicated form service that stores user-defined forms and their respective answers. Both the Report and Inspection entities then reference the answers by ID rather than storing them directly.

Pros:

Single Point of Management: The logic for handling forms would be centralized in one place, making it easier to manage changes or updates to the form structure.

Cons:

Complexity in Domain Constraint Management: Following domain constraints is trickier without tightly coupling these services or incurring the overhead of complex saga patterns, which can introduce additional latency and complexity.

Recommended Service Breakdown

From the above approaches, a third solution could involve defining specific services that handle different aspects of the form and report lifecycle. Here are some potential services to consider:

FormCreationService: Handles the creation of user-defined forms.

FormFillInService: Manages the submission of form answers.

ReportsService: Maintains a state machine to ensure that only valid state transitions are allowed for reports.

InspectionService: Similar to the ReportsService, ensures that inspection states are valid.

Moving Forward

Once you define these services, the next step would be to outline APIs for each service. Utilizing tools like sequence diagrams can help validate these APIs and en