Sharing data between (macro) microservices \w replication or fetch-on-demand?

Question

I'm working on a complex system that follows the principles of microservices, but with one exception - my services are more 'generalized' and big (I refer to them as macroservices further down the post).

For example, instead of having very precise services:

• users
• news
• articles
• posts
• threads
• matches
• items

I have the following generalized services instead:

• portal (users, news, articles)
• forum (users (from portal), posts, threads)
• game (users (from portal), matches, items)

I understand that it affects scalability, flexibility and coupling - but this design choice has its reasons, and it's not the problem I'm facing either.

The problem

As you can see above - all of the macroservices use users resource originating from the portal service.

Generally speaking, once you register on the portal - you can use the same account to play the game or post on forums.

Question:

Should I implement cross-service communication, so game and forum fetches user from portal when needed (quite often, as every post, thread and match has user(s)) - which means they can't function once portal dies, but the data will always be up to date.

OR

Should I implement data duplication/replication, so whenever UserCreated, UserUpdated event fires - game and forum stores a duplicate of user in their own database - which means they can still function if portal dies, but there's a bit of coupling due to synchronization.

Answer 1

Since we established in the comments that you need more than SSO, which would have been the simple answer, for sharing the data between the three "macro"services the answer is a little bit more complicated. And it's more complicated because the answer can only be "it depends".

Both your approaches have advantages and disadvantages. Fetching user data from "portal" every time it's needed inside "forum" and "game" will allow the data to always be up to date but might cause performance issues or slow response times of the applications while you constantly fetch data (and if "portal" is down, so are the other apps). Data replication with update events can cause the services to see different data at the same time if some event is lost or replication hasn't yet propagated all the data. You now have eventual consistency and data in three different places. Change the schema of users in "portal" and now you need to make changes in two other places.

The answer is "it depends" because the solution you choose (one of those two, or some other) heavily depends on your use cases. So this is the first thing you should do. Look at all your use cases and see which solution would work best in each case.

With that being said, and the fact that you are dealing with user entities, which shouldn't change all that often, I would personally go with replicating the data. You have various options and tools available: you can do an initial dump of users data then subscribe for changes, your RDBMS (whatever you are using) might be able to handle the replication in a master-slave configuration, use a lighter NoSQL solution to distribute data, a CDN even (depending on what data you need to replicate), etc., there are plenty of options. Be very careful though to keep the replication as decoupled as possible as things like databases often introduce a very tight coupling between services ("micro" or "macro" as they may be).

If users are aware that changes to their data will take some time to propagate, it won't be an issue.