CODEWITHSUNDEEP
microservices
anupam
anupam

Reputation: 357

Microservice Data Duplication vs Single Responsibility

I am new to microservices and trying to break up a big monolithic application into microservices. While scoping the microservice I am unable to decide whether I should go for a data duplication between services or ignore SRP by clubbing all requiring the same data into 1 service. Following is the scenario.

I have a service which receives Customer order say build a car with these parts and features. Now I have other 2 functionalities which uses the Parts and features to derive some runtime value say ;

If the order contains part A and Feature A then perform X operation. As each of these functionalities have there respective UI for configuration and runtime engine to derive the output and most of the time changes only comes in these respective function blocks, I thought of creating the separate microservices.

Creating the separate microservice would need data(Parts and Features) to be duplicated. Another option could be given each of these service uses the same data is clubbing all of them into 1, but with that I again create a big service which if goes down will stop all 3 functionalities and is against SRP. Another option could be when the data is required by the other 2 services make a call and get it from Order Service, but that is making it highly dependent and getting the data over network for each operation.

Can anyone suggest what would be ideal to do in such case.

Upvotes: 8

Views: 8599

Answers (4)

Vaibs
Vaibs

Reputation: 1606

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.

enter image description here 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

Upvotes: 3

John Scharber
John Scharber

Reputation: 73

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.

Upvotes: 1

Saurabha
Saurabha

Reputation: 114

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

Upvotes: 0

vaquar khan
vaquar khan

Reputation: 11449

This is my free book :)

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.

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

Upvotes: 1

Related Questions