4

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?

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
4
  • 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.
    – Trace
    Commented Aug 23, 2018 at 9:20
  • 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.
    – manntsheth
    Commented Aug 23, 2018 at 23:51
  • 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.
    – Trace
    Commented Aug 23, 2018 at 23:58
  • Facebook, YouTube and most of the companies use pre-fetching at great level.
    – manntsheth
    Commented Aug 23, 2018 at 23:59

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.