Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
What is the best practice for logging user-related data in microservices architecture?
In example: I would like to audit/persist to database information on who deleted a resource.
I have user info on the first (client-facing) service, but I don't pass it further.
I wonder if there is a smart way of doing it - like injecting some generic filter to decorate all requests with user-related headers?
Let me assume your microservices communicate via HTTP. We hit the same question when designing your microservice approach so let me share that:
First thing we recognized was, that there is no way around handing over some kind of user information with every cross-service request in the backend. Now, how this user information in structured is not that relevant. We kept it very simple. Since we use token authentication we just hand over this exact token from service to service. (Your problem is very similar to this one)
And yes, that approach requires every service to re-enumerate user information for this given token from some kind of token-service. Since this happens once and only once (make sure of that when reviewing code!!) per request, we decided we'd take this road and optimize the hell out of our token-service (we'll publish it as opensource soon!). But it also enables some interesting possibilities like services that can use a token of their own to impersonate a user and perform actions on it's behalf, while the service receiving this impersonation token can query the information from the token-service in exactly the same way it would without impersonation!
To summarize: We hand over the access token in all cross-service calls to keep the overhead in the request to an absolute minimum, adds only a constant number of additional cross-service requests!
