Micro Service Cross Service Dependencies

Question

Just to simplify my situation, I currently have 3 microservices.

• Authentication
• Location
• Inventory

The authentication service authenticates the user and sends back the JWT access token, and I use it through other services. Its stateless and everything works well.

I set places among other things in the location service, and it works well and as expected.

But now I am in the inventory service, and I need to add some inventory, but it is related to the location. I can easily pass the locationId in an API call, but I have no way to allow the current user to add something to this place unless I call the location service to verify this.

This creates interdependencies between services, and this is what I am trying to avoid at all costs, otherwise you will simply lose most of the benefits of microservices.

What would be the recommended approach to verify that the current user has permissions for this location? The only thing I've been thinking so far is

• Getting the location API to issue another access token with additional statements about where they have access.
• Or issue another completely separate token of some type and pass it through the header to the inventory firmware to perform a check similar to JWT authentication.

Edit

As mentioned below, in order to provide aggregate roots (or I assume that this means the same as API gateways), it will provide a third option of another service from above to communicate with both to provide information.

However, after this, the 3rd service remains dependent on 2 others, so I just increased my service dependencies.

Answer 1

The microservice design is bad. You model ( location and items ) 1 class = 1 microservice, and this is not a good idea.

You use simulated microservices such as Aggregate Roots in DDD ; even with its own limited context. So, in your case, you should simulate Aggregate Root using location , items and user , which allows you to check the domain rules in item addition user action . It could be, for example, in your Stock Context .

Of course, this does not mean that you should not have a Wharehouse Context in which you can add, modify and / or delete locations and (if there is no need to check the domain rules) Aggregate Root simply a Location class . But this is a different microservice in a different context.

This post should help you. It will bring you big A-HA! in your mind after reading.

Answer 2

While @jlvaquero provided this idea above, I just wanted to indicate what my actual solution was and why.

He then goes on to this setting.

Verification is now performed at the gateway level. The only thing I have to some degree of uncertainty here is the fact that I am currently doing an entity check outside the service, which should be responsible for this domain.

The inventory service simply accepts that the user is allowed to connect to this location. But, given that the location and user verification is outside the service domain, it is consistent with the fact that he should not touch this verification.

Answer 3

The gateway should only authenticate, not authorize. Permissions are processed internally by the service, because the services only support those who can access it. I would get an inventory service to get a list of places the user has access to.

All orchestration will take place at the user interface level so that inventory services do not create a strong dependence on the location service.

This is one approach - not sure if this will work for you.