Local user cache in posts microservice

Question

Given following microservice architecture:

enter image description here

Every post has a user, for which we want to have all information available.
Is more custom to:

• Have a local user cache in the posts microservice
• Make api calls to the user service on every request
• Store user information along with every post

I don't particularly like the last option when storing in the database; because of duplication, but also because it doesn't update the user data when something changes.

What is your take?

Answer 1

There are multiple options

1. Instead of storing all data about a user in the post object, store only minimum info which you can show when someone hovers over username. If a user clicks on username then you can make a separate request to user micro service to get a detailed user object.

2. If you really want all info of user (and you don't like option 1) then while you are sending n number of posts to UI (make a batch query to Cassandra to get all n users' objects). I am not sure if Cache has a capability to find all objects for all keys. (ideally cache should have that capability).

3. Similar to 2... Instead of calling user microservice for each user you can develop an api endpoint which can fetch bulk response including multiple users' data

It is not ideal to have user cache in post microservice, in future it will make your life difficult to make sure user cache in post micro service is in sync with user micro service data. Cross dependency isn't a good option. If two independent teams are working on it, it's not ideal.

• Trace: Thanks, the problem is that streams of posts will contain users with a link to their Facebook profile url. This profile url can change. If they change their username, the link will become invalid. Your solution works, I'm just a bit off by the overhead of an extra http request, which eats off the time it requires to receive the feed in the client.
• manntsheth: You can preload posts so users won't see a delay. For example if user device has first 50 posts loaded already, then it will take some time for user to scroll through. During this time server can prefetch another 50 posts in background. But this all should be implemented on later on phases. It can be carried out gradually after completing initial project.
• Trace: Mm yes but you don't know if they will actually request the next 50 posts. This seems a bit brittle. Thanks for your input anyhow.
• manntsheth: Facebook, YouTube and most of the companies use pre-fetching at great level.