I have a interessting question about microservice architecture. The case is I have multiple service that need one central information regarding permission. In our architecture all the microservices manage the permissions themself, but a user in our system can have multiple companies that he is allowed to manage. Almost every route in the system needs the company_id in the request. Theoretical the User X can remove user Y from a certain company, if User Y now tries to make any action on this company he should be not allowed anymore. But any service must know that the user is not allowed to access not at all anymore. For sharing this data between all the services there are 3 possible approaches:
1) If User X removes User Y from a company the service will put a message in a Q and the worker informs all the other services about this change. 2) I use a Zuul as API Gateway theoretical the API Gateway could check on each request (that has a company_id) in the request if the user is even allowed to access this company. But this means the API Gateway itself would have to make a database call, which is not nice because the Gateway should be a gateway and nothing else. 3) I could use a global datastorage that is replicated on each microservice, for this I could use for example etcd. Each microservice can check if User Y is allowed to access the company.
Important in all the cases is that if user Y is allowed to access the company the microservice itself still has to check if user Y is allowed to make a certain action on this company. So this user to company matching is only for making sure a user has access at all to a company.
I am not really happy with any of this aproaches, because putting the message in the queue (1) means that every single service must be informed about a change. Using Zuul to verify (2) is also not really practical because it should be only a gateway.
In my opinion there is no such thing as global data. All the data is localized to one given service which is owner of it, and others can make a call get this data. Replicating this data in other microservices can lead to an inconsistent states.
For this very use case why don't you try authorization route. When userY logs in your system you authorise him to have access to certain company. One or more. This information can be passed in the token and each service which cares about company id can pick it up and work on it, Since tokens have limited time to live, as soon as userX removes UserY from a company, subsequent tokens will not have company_id and will be ignored.
Here your logic is in Auth service, and others just looking for this information in headers. If you don't like the idea of auth service you can add one service which adds company headers to all incoming request once. (This is different from API gateway doing it because api gateway has other responsibilities).
Your data is not replicated by different services, there is one place to manage all info about company header