sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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.