My situation probably leans more towards the bad/convoluted code wasting cycles scenario. But okay, i think i have a good amount of information now, thanks for the input.

What i meant was the runtime location of player related data. Is it common to have it reside partially in multiple locations

It's pretty common that what you think of as a "player" is made up of many different facets.

For example, the credit card information for a player typically doesn't live in the same place as the current character's strength attribute. And characters "at rest" that belong to the same player probably aren't inflated onto a game server, whereas a character actively being played has one or more instances in RAM. (Multiple instances can happen when you do seamless migration between servers.)

In general, it's important to be able to split the data across multiple places. When doing so, it's important to design your data models so that it's OK that forums badges lives in the forums, character stats live on game servers, and payment methods live on your payment provider.

Exactly how this split happens, depends on game specifics. You can also go pretty far by saying "anyone can read a potentially stale facet, but only one place can write each facet." So, your forums could read the data for a character, to display "playing an 11th level samurai" and if it turns out that you just leveled up on the game server and that facet hasn't made it back to cold storage yet, that's OK.

The really exciting code (and bugs) happens when there are things that must live in multiple domains/facets. For example, if you allow a special inventory item to be purchased with dollars, then there's some operation that needs both to verify a dollar purchase, and affect the inventory of a character, and if you don't get it right in both places at once, player will be very sad.