0
votes

I have a below requirement in Microservice architecture desgin. My project which is of type Azure Service Fabric stateless and stateful services in Dot Net Core. enter image description here

Total 3 stateless and 3 stateful services in that project.

For Each stateful service we have created one stateless service as gateway to that.

We will be storing data in stateful service and through stateless we will sending data and retriving data.

For communication purpose we will be using Service proxy(ie. IService implemented interface).

I can easily call methods of stateful1 from stateless1, But I have requirement like I need data from stateful1 which is depended on the stateful 2 and stateful 3.

I have some business logic in between each stateful service,

Currently am creating Service proxy on statful1 and gathering all the data of stateful 2 & 3 and after comuting entire data will be sending to stateless.

My question wll be, Is it better to have one more layer called repository(Class library project used by the stateless) which will contact each stateful service and comupte the business logic?

Or If have antire business logic in stateful will impact on performance, instead of having business logic in stateless.

I have taken simple example of 3 stateless and 3 stateful, But actually my project consists of more than 50+ services each one is having Gateway and stateful service. Between each stateful service I have more business need to write.

Please suggest me better approach for doing this requirement.

1
I didn't get you?SRINIVASREDDY VELPULA
That makes two of usErik Funkenbusch
Can you describe why you need a gateway service? What drives this requirement? Are there direct calls to stateful2 and stateful3? What I mean is that is there are use cases when we need to return data directly from stateful2 or stateful3? Or these services are only used by stateful1?Oleg Karasik

1 Answers

1
votes

Your question has a lot of context it seems, not all of which will be obvious to a reader.

A microservice architecture seems to me like a "big hammer" to pull out of the toolbox unless the problem you are trying to solve, with the system you are creating, cannot be appropriately solved in any other way.

When I hear you talk of 50+ services, each of which have a counterpart so actually its 100+ services, my first suspicion is whether this architecture of yours may be over-engineering? But then again as I already pointed out a lot of context is missing so it's hard for me to really make that assessment.

Perhaps you should consider if it might be beneficial for you to merge stateful service 1, 2 and 3 as you call them?

The situation you are in might be a symptom that those services are tightly related and could benefit of being merged together.

I was in a similar situation recently where 2 microservices (who should have been 1 in my opinion) dealt with closely related data, one was a case-service the other was customer-background-check service, the business requested an export data to csv-file where each line in the desired output csv-file contained a combination of data from the case and the customer-background-check. The only way to achieve this was to iterate over the cases and for each case make a call to the customer-background-check microservice which of course scaled horribly. 1000 cases would mean 1000 http calls. If it had been 2 tables in one SQL database however you can easily imagine how simply this could be solved with a single join query.

Sometimes less is more.