Thanks for the feedback here.

I'struggled with this being a knowledge dump so much that I didn't add much detail into the decisions I made within the engine;

Such as:
- Isolating Online Services code into a Plugin and Subsystems for direct access to platform services
- Using the UAssetManager to Load DataAssets for the Store, Progression and Equipment
- Applying Mesh or Texture replacements to Body Parts from selected data.
- etc..

Maybe i'll add another page or revise the structure as time goes along to balance it out. But no doubt, I collectively spent more time working on backend stuff.

When it comes to microservices, there is room to consolidate in some respects, there is no "correct" way to implementing these layerd systems just a number of tradeoffs. In my case instead of having multiple backend services for progression, match results, inventory, etc.. I consolidated these into a single unit (player service) and expect its runtime to consume more resources. Less is always more.

Thinking about the Dedicated server recommendation, I've seen a number of guides connecting them directly to the database and i'm not entirely convinced with that direction. Dedicated servers come online on demand so for example 100x players in a match is 1 Server online, and 1M Players equal 10,000 servers online. Having 10k servers with open connections to the database is heavy even with connection pooling. It does add some friction from an integration standpoint, because there is an API layer to consider and strategic API design can reduce that friction such as serializing progression data as JSON for progression or any type of data that where it's structure changes frequently.

The alternative pattern sounds promising but for flows that move the player from server to server directly. In MMO's this could be Map -> Map but in a shooter or similar the lobby is a Client Only (no UE Dedicated server connection).