Microservice Data Duplication vs Single Responsibility

Microservice should communicate via events using publisher/subscriber model and topics. See the tri-lateral design pattern. In a pub/sub system the producer writes the event to the topic and a broker makes it available to each subscriber, aka microservice. This is one advantage of eventing, one producer, and many consumers.

Order A has a BOM that expresses parts and features an order represents. When the order is placed, other services need that information such as the feature/part microservice and UI components and their respective datastores. For example, define two topics parts-ordered and features-ordered.

The order microservice writes to the parts and features topics respectively. The feature, parts, and UX microservices read and act upon those events.

You need to make a choice about your system of record. You can write to an orders DB before publishing the events, or let the pub/sub it. In your example, it sounds like you are talking about three different tables; order, parts, and events. That decomposes cleaning into the microservices you describe where each maintains the data it is responsible for. I'd be inclined to just use the pub/sub as your audit trail.

If you are writing in Go we have blueprints for the most common design patterns.

First, you mentioned that you are trying to convert the monolithic application into microservices. You can create/caters the microservices on basis of domain data, we can be called it domain-driven architecture.

Suppose you have the business functionality for customer data, customer order, customer order handling, and customer payment. And currently, it's part of a monolithic application. So you can create the subdomain for each functionality like Customer domain, Order domain, order handle domain, and payment domain respectively. Each domain contains several microservices depends on the business requirement.

For e.g you can check the Amazon website, In personal/customer data, you see the customer name, phone number, address, billing account information, delivery address type(office/home). In this case the under customer domain, there will be 3 microservices required(It totally depends on your domain design). One for customer(handles customer name, phone number, reference of Billing account id, reference of address id), second for Billing account(Billing account number, billing account information, reference if customer id), third for Address data(customer office address, preferable address). And for each microservice, there will be a dedicated database/buckets, Only that microservice can change/add the data. If any other microservice wants to add/update/get data, it needs to be get by calling that microservices HTTP endpoint over the network.

Updating the data in other microservice::

Now coming to your question about data duplication, Let's consider the above example. If Customer microservice wants to store/ cache the billing account data for some purpose, that microservice can store that data in the database but again Customer microservice needs to make sure that, the current data of the billing account is always real one and not the old one. For this customer, microservice needs to listen to the event whenever there is update in billing account data, so old data in billing account gets purged and customer microservice always has the latest data of billing.

you can read here about event driven architecture.

https://en.wikipedia.org/wiki/Event-driven_architecture#:~:text=Event%2Ddriven%20architecture%20(EDA),sale%22%20to%20%22sold%22.

You can read more about this at the below links about Domain driven design.

https://www.thoughtworks.com/insights/blog/domain-driven-design-services-architecture

https://en.wikipedia.org/wiki/Domain-driven_design

This is my free book :)

• https://github.com/vaquarkhan/microservices-recipes-a-free-gitbook

If you want to create microservice then need to follow microservice guideline.

Now come to real world :) really difficult to meet all microservice requirements as database has own licensing cost etc. so you can choose pragmatic microservices. You can get started with them faster and pick and choose the pieces that make sense for your team.

Design Domain driven design oriented microservice : DDD talks about problems as domains. It describes independent problem areas as Bounded Contexts and each Bounded Context correlates to a microservice.

Where to draw the boundaries is the key task when designing and defining a microservice.

DDD patterns help you understand the complexity in the domain, the domain model for each Bounded Context, you identify and define the entities, value objects, and aggregates that model your domain. You build and refine a domain model that is contained within a boundary that defines your context. And that is explicit in the form of a microservice. The components within those boundaries end up being your microservices.

• https://martinfowler.com/bliki/AnemicDomainModel.html
• https://github.com/vaquarkhan/Domain-driven-design
• https://github.com/vaquarkhan/ddd-by-examples.github.io/blob/master/ddd-factory.pdf

Now you can create layers on top of you microservice and build complex logic using orchestration and choreography.

Example :

Gateway  Customer order Application layer microservice --domain model layer microservice  infrastructure layer

There are various ways to decompose an application into services.

1.Decompose by business capability

2.Decompose by subdomain

And there are various ways for data management also

1. SAGA
2. API Composition
3. Database per service

Please go through with the link for more details click