Because there are many ways of looking at this and as many ways of solving your challenge, some personal from-the-top-of-my-head thoughts on this while lacking an answer to myriad questions that anyone would need an answer to before making any sort of truly informed decision would be this:

• Data duplication in a microservices architecture is unavoidable and even desired, depending on your situation. In terms of performance, it might be preferable to have data come from a single service and not have to query multiple apis. Nothing's holding you back of course, it just forces you to deal with possible inconsistency on the consuming side without a clear single source of truth. Don't worry too much about duplication. Storage is cheap. Whether you keep some id in sync or an entire record really makes little to no difference.

• One of the standard ways of providing (eventual) consistency across microservice databases is some sort of enterprise service bus mechanism. Each service can publish data onto the bus and interested parties can subscribe to channels on the ESB. I'd avoid point-to-point communication. It doesn't scale well as it's too tightly coupled. Keep your services oblivious of one another. In that regard, I'd personally refrain from federated queries on the PSQL level. Mind you, setting up a good service bus is no mean feat. Synchronization is never trivial, however you decide to implement it but it does get easier once you've done the groundwork.

• You could keep your individual microservices that communicate amongst themselves over the ESB in the background and offer a search provider like Elastic Search that does the aggregation and indexing and serves as a data storefront, alleviating many of your microservice data duplication concerns and keeps the services "cleaner". It also integrates with most garden variety databases.

• If you have a need for a leaderboard and you worry about querying multiple apis, then why not simply make a leaderboard microservice?

Of course, none of us can judge whether all this is a good candidate for your case. Much will depend on team, time, budget, need for scaleability and any number of other questions that you and you alone can answer. These are all just personal musings.

Because there are many ways of looking at this and as many ways of solving your challenge, some personal from-the-top-of-my-head thoughts on this while lacking an answer to myriad questions that anyone would need an answer to before making any sort of truly informed decision would be this:

• Data duplication in a microservices architecture is unavoidable and even desired, depending on your situation. In terms of performance, it might be preferable to have data come from a single service and not have to query multiple apis. Nothing's holding you back of course, it just forces you to deal with possible inconsistency on the consuming side without a clear single source of truth. Don't worry too much about duplication. Storage is cheap. Whether you keep some id in sync or an entire record really makes little to no difference but I would certainly not deal with inconsistencies at application runtime. It's simply not an application's responsibility.

• One of the standard ways of providing (eventual) consistency across microservice databases is some sort of enterprise service bus mechanism. Each service can publish data onto the bus and interested parties can subscribe to channels on the ESB. I'd avoid point-to-point communication. It doesn't scale well as it's too tightly coupled. Keep your services oblivious of one another. In that regard, I'd personally refrain from federated queries on the PSQL level. Mind you, setting up a good service bus is no mean feat. Synchronization is never trivial, however you decide to implement it but it does get easier once you've done the groundwork.

• You could keep your individual microservices that communicate amongst themselves over the ESB in the background and offer a search provider like Elastic Search that does the aggregation and indexing and serves as a data storefront, alleviating many of your microservice data duplication concerns and keeps the services "cleaner". It also integrates with most garden variety databases.

• If you have a need for a leaderboard and you worry about querying multiple apis, then why not simply make a leaderboard microservice?

Of course, none of us can judge whether all this is a good candidate for your case. Much will depend on team, time, budget, need for scaleability and any number of other questions that you and you alone can answer. These are all just personal musings.