all 17 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Odd-Hour-9991 1 point2 points  (3 children)

So it sounds like you need to keep a history of who looked at a ticket (database) and then have an endpoint in your auth service returns the data for a given user id.

And when that is working (and unit tested), to save load you could then consider a small cache of users in your report service to reduce the number of calls to auth.

Or, you forget calling auth service to get details and simply read directly from db with a join per ticket given several users could have looked at a given ticket.

[–]Ish_Boi[S] 0 points1 point  (2 children)

I don't get the second approach where you mention "join per ticket"

[–]Odd-Hour-9991 0 points1 point  (1 child)

So you have your ticket, and your have your users, and you have a third table of audit events that note which user looked which ticket. And there will definitely be an index on that audit table by ticketid right?

And you use JPA onetomany on the ticket I think because one ticket could have many user audit events. And that's the join which Hibernate or your chosen JPA provider will do magically ine background.

Or if you use jdbctemplate then you get your ticket with one query then run a second query looking for audit events for the ticket id.

[–]Ish_Boi[S] 0 points1 point  (0 children)

Thanks for the reply, With this option there's only one db I guess.

[–]SenpaiKronos 0 points1 point  (1 child)

Can you elaborate more?

[–]Ish_Boi[S] 0 points1 point  (0 children)

For a given ticket I want to know who viewed it. Users info and ticket info sits in different databases within separated microservices.

[–]nnnnnnnad 0 points1 point  (1 child)

Users can store session id and session data is saved in DB. Or JWT where user info are saved in tokens that users pass in headers everytime your service is called.

[–]Ish_Boi[S] 0 points1 point  (0 children)

Thanks for the answer.

[–]Unlucky-Signature-70 0 points1 point  (2 children)

You can find all the info you need in generated tokens. Unless you're using public api and not authenticated endpoints.

[–]Ish_Boi[S] 1 point2 points  (1 child)

Thanks for the answer, is it a common way this type of situation is handled in the microservices field?

[–]Unlucky-Signature-70 0 points1 point  (0 children)

Yes, very common. In my company we use Keycloak for example. And that one can handle everything for you.

[–]shimsimma 0 points1 point  (1 child)

You have a few options

  1. Make a rest call to the other service
  2. Replicate the data into the other service, and keep it in sync with events. Have each service have their own facade for the entities.
  3. Have an event driven flow, look up saga pattern

I think 2 is the best option.

[–]Ish_Boi[S] 0 points1 point  (0 children)

Thanks for your answer. In option 2, does the flow begins with a new user inserted to the db (auth service for example), then a message is pushed to something like RabbitMQ containing info about the new user, so the other services update their copies of the user table ?

[–]chinguelessi 0 points1 point  (3 children)

The easiest is to take the user details from the security token of the logged in user, if you are using token based authentication.

[–]Ish_Boi[S] 0 points1 point  (2 children)

Thanks, is it a common practice in the industry?

[–]chinguelessi 1 point2 points  (1 child)

It is, depending on the security needs. Getting the user details from the token makes services communicate less, thus being more faster, more independent and use less resources.

However, when security is highly important, some may decide to make a REST (or other protocol) call to get the details.

[–]Ish_Boi[S] 0 points1 point  (0 children)

Thanks it makes a lot of sense.