CODEWITHSUNDEEP
microservices
John M.
John M.

Reputation: 119

Composite/Aggregate Service in Microservices

We are preparing a move from a monolith to a microservices model, and as part of that move I am preparing a design and break up of our services. I am increasingly finding a pattern re-occurring, which I have seen on the web being called a composite or aggregation service, and I am not fully clear on it.

My question is two parts:

First, the pattern that I see is that I have cases where in one call from the UI I need to talk to get data from 2 or more services. Lets call these service A,B and C. Now, I can create another service say service D which will do the orchestration for just this particular call, and will manage the downstream calls to service A, B, and C. I see this as being referred to as a Composite or Aggregation service. My confusion with this is, now each time i need some coordination, I have to create another service that sits one level above the atomic services, just for coordination.

Also, this seems much like a BFF(Backend For Frontend) pattern, but in my case, I am having multiple 'Composite' services that make up my BFF. I am not sure, but I think for a BFF you have one big 'Orchestration' service for all of your UI calls, even though that could be a SPOF and seems like an anti-pattern.

My question therefore is, should i have these 'micro-orchestrators' such as service D in the example above to do the coordination ? Or should i just let each of the services make a direct call to any service they are dependent on data for ?

Second, should I just implement one layer above the atomic services for all requests, I have seen this go by many names orchestration/api-gateway/edge-service, or have multiple of these 'micro-orchestrators' or composite services ? If there is just one service in the top layer, such as an api-gateway, this would seem like an anti-pattern since now there is a SPOF, but I see it being recommended as the way to go.

Just to make it clear, I will provide concrete example of the situation I have described above, and what i would think is pretty common. From the UI there is a log in page, upon entering their username/password we will verify the credentials and if they're correct, pass back all the users information.

There would be 2 services to accomplish this, an Authentication service to check/validate the users credentials and a User service which would get all of the data. How should this simple call be coordinated, so that if credentials are valid, we return back data from the User service in the same api call, and if not we only return an error from the Authentication service. Should there be a composite service that coordinates the call to these 2 services, or should the services interact directly with AuthService making a call to User service if credentials are valid ? And should this just be one composite service out of many, or should all composite services be put together into an api-gateway type service ?

I have already looked at the following, but that doesn't really provide any clear answer. My question is not only about the composition of services, but also whether there should be one such composition, i.e, an api-gateway, or multiple composite services for each interaction that requires it.

How do you handle validation in composite microservice request?

Upvotes: 2

Views: 2783

Answers (1)

Saptarshi Basu
Saptarshi Basu

Reputation: 9303

Authentication and authorization is a special case where an OAuth 2 authorization server authenticates the users against an authentication server (viz. LDAP, etc.) and return tokens. It is mainly designed based on OAuth 2 specification. Let's keep that aside for the time being.

Service orchestration is sometimes done. But if you frequently see yourself in a need to do service orchestration, you need to consider a few other things:

First thing you need to check if you have correctly identified the bounded context of the services. In other words, is the logical division of responsibilities among the services correct?

If you are happy with the division, you need to implement one or more of these patterns:

  1. CQRS / materialized view
  2. Saga
  3. Event Sourcing

The approach to handle this kind of scenarios with CQRS and event sourcing is explained here: https://stackoverflow.com/a/54676222/1235935

Upvotes: 0

Related Questions