I’m having a problem choosing the right approach to sharing some user related data throughout my microservices-based application.
Imagine the following scenario:
Users microservice handles creation of users, but also management of the hierarchy of those users. It has the information regarding which users have
Manager role and which
User role, but also which
Users are subordinates of which
There’s also a
Books microservice which allows for creation and management of
Book and related entities. Users can create and manage their own
Book, however, their managers should be able to update their
Book, too. The authorization of
Update endpoint of
BooksController should check if the
User trying to do the update is the owner, or in the case when he’s not, does he have a
Manager role and also if the owner of the
Book in question is his direct subordinate. This information is only available in the
I’m considering following solutions to this problem:
A request/response pattern implementation to get the subordinates of the
Managerin question – Feels like a very bad option for this, as it’s essentially creating a tight coupling between the services and also creating a single point of failure for both services.
Booksmicroservice (read-only) – another case of tight coupling, however, with no dependency of the
Usersservice to be alive to retrieve the information.
Merging the microservices together – Maybe the line was drawn in a wrong place and those two microservices should become one. However, looking at the
Usersservice, it feels like this sort of scenario can reappear for other microservices that will be introduced to the application. Solving it this way sets a precedence for just merging it all back together into a monolithic application.
Adding the data regarding users hierarchy to the access token as a custom claim and using that data to do Authorize in the
Booksservice – I think it could work. My worry is that I’d be misusing custom claims for passing data that isn’t really ‘part’ of the user.