1

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?

5
  • How are you authenticating/validating your actual deletion requests? Is your database/server just... trusting all deletion requests?
    – enderland
    Commented Jun 17, 2016 at 12:43
  • Authentication is done in user-facing service only, which then calls other, internal services, including the one accessing DB.
    – FazoM
    Commented Jun 17, 2016 at 12:45
  • It's a bit vague. How are your micro-services communicating? Can't you simply pass the user as additional parameter?
    – dagnelies
    Commented Jun 17, 2016 at 13:16
  • What is the data store, and does it include provisions for this sort of logging out of the box? Example: in most SQL RDBMS's, you can use a trigger for this. Commented Jun 17, 2016 at 16:26
  • Why cannot you just log it directly in the place where the action is fired, if it was successful?
    – Andy
    Commented Jul 15, 2016 at 6:31

1 Answer 1

1

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.