Micro Service cross service dependencies

Question

Just to simplify my situation I currently have 3 micro services.

1. Authentication
2. Locations
3. Inventory

The authentication service authenticates the user and sends back a JWT access token and I use that across the other services. Its stateless and all works well.

I setup locations among some other things in the location service and this works well and as expected.

But now I am at the inventory service and I need to add some inventory but it is linked to a location. I can easily pass the locationId in the API call but I have no way of authorizing the current user to add something to that location unless I then call the location service to validate this.

This then creates service dependencies between each other and it is something I am trying to avoid at all costs otherwise you just lose most of the benefits of micro services.

What would be the recommended approach to validate that the current user has permissions for that location? The only thing I have thought of so far is either

1. Getting the location API to issue out another access token with additional claims of what locations they have access to.
2. Or issuing out another completely separate token of some kind and passing that via the header to the inventory micro service to do a validation similar to how the JWT is authenticated.

Edit

As mentioned below on providing aggregate roots (or I am assuming that means the same as API gateways) it would provide the 3rd option of another service on top to communicate to both to provide the information.

However it then leaves a 3rd service dependent upon 2 others, so I just increased my service dependencies.

Answer 1

You microservice design is poor. You are modeling (location and items) 1 class = 1 microservice and this is not a good idea.

You shoul modeling microservices like Aggregate Roots in DDD; even with its own bounded context. So, in your case, you should model an Aggregate Root with location, items and user that allows to check domain rules at item addition user action. This could be, i.e., in your Stock Context.

Of course, this doesn't mean that you should not have a Wharehouse Context in wich you can add, modify and/or delete locations and (if no need of depencies to check domain rules) the Aggregate Root is just Location class. But this is other microservice in another context.

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