Originally Posted by xero

I'm not making a mistake per say, i'm just not taking into account their environment, even if they are in AWS and dynamically scaling and all that jazz, the simplest solution is still the same. There's just some additional wrinkles due to things like logical physical hardware mappings, replication, and other wonderful software "wacky-ry" that will complicate things a bit.

The cache can be distributed. Sharding it on say... user hash would do the trick, the hash mapping to a virtual node so that the physical node underneath can be replaced through some sort of magical re-balance/re-shard operation. They probably don't need to dynamically scale for this deployment. I wouldn't be surprised if its still setup to do so, since its pretty common for web based games, having a couple under their belt already they probably design to make it possible to scale as a matter of standard procedure at this point... (its a good feature to have available incase your player base suddenly explodes, or dwindles... which of course it does naturally over the course of each and every day)

Basically I was assuming they have storage/cache that is reliable and available for each player, and i'd say that's pretty reasonable. considering you have an inventory, stamina and life counters, cards, and many other things stored/cached that are specific to you, just tack the results from the query on to the end of that. =)

The problem is that doing things in web services like this is best geared by moving to as much of a REST architecture, where you don't cache this kind of things, as possible.
Caching, and sharing data between distributed parts of a server, are such complex things that there are whole companies and profesional groups just dedicated to that, and they can't fix it good enough yet.
Believe me, caching trivial transactional data in a distributed web server is as hellish hard as you can go.

Game can remember who I have thrown a pie at so why cant it remember who I have attacked ??

There much fewer Sexy rank 1 players then Moe ranks 1 players (Around 150 players rank 1 sexy players) to get 60 kills per hour you need to find youself in 60 sek and press attack. On avarage you need 12 refresh to find youself - is 12 refresh in 60 sek is that imposible?? There are 3-5 times more Moe players so it would be hard to do for a moe player.

All the top player are sexy rank 1 players.

I tested by making same deck as one of the top players - I got 1 defence win in 30 min he had 30 defence wins in same 30 min ????? How can this be posible ?????

Originally Posted by Unregistered

Game can remember who I have thrown a pie at so why cant it remember who I have attacked ??

Because remembering something is not caching.
Caching is keeping that data it remembers floating on memory (or any fast-access space) so you don't have to spend the resources it takes to go fetch that data from the database it remembers it in

- - - Updated - - -

Originally Posted by YoshiEnVerde

Because remembering something is not caching.
Caching is keeping that data it remembers floating on memory (or any fast-access space) so you don't have to spend the resources it takes to go fetch that data from the database it remembers it in

Virtual servers work in a simple way:
You keep your data in one server (or set of servers), and your logic in another server (or set of virtual servers like in this case).
That's what allows a hundred virtual servers to work at the same time: They all share the same data space.

Caching is used to avoid the need of accesing that shared data space as much as posible (as using local data will always be faster than asking for data from the data space).
As such, distributed caching becomes a big nightmare.

The virtual servers are pretty much a huge set of small pieces of code, with no state being saved between request and request.
The virtual servers do one simple thing: Recieve a Request -> Process It -> Ask Data Space for Needed Data -> Return Response to App.
They don't remember who you pied, unless they ask the data space for that info.
Making an algorithm that filters certain players based on time since you attacked them means multiplying the complexity (and cost) of the search service by at least 3 or 4 times, and it's quite slow already (anything that takes lapses in the range of seconds is considered glacial in web services)

- - - Updated - - -

Originally Posted by Unregistered

There much fewer Sexy rank 1 players then Moe ranks 1 players (Around 150 players rank 1 sexy players) to get 60 kills per hour you need to find youself in 60 sek and press attack. On avarage you need 12 refresh to find youself - is 12 refresh in 60 sek is that imposible?? There are 3-5 times more Moe players so it would be hard to do for a moe player.

All the top player are sexy rank 1 players.

I tested by making same deck as one of the top players - I got 1 defence win in 30 min he had 30 defence wins in same 30 min ????? How can this be posible ?????

It's not the 12 refresh per minute that is a problem, it's refreshing and checking your name isn't there, which takes cognitive action beyond the reactive action of clicking over and over.
Also, we're not talking about 60 kills per hour. We're talking about 100 to 200 kills per hour (top5 players rake in def counts of 300 to 400 in 2 to 3 hs). That's 20 to 30 seconds per attack, meaning 12 refreshes in 2 that time, or 1.5 to 2.5 seconds to refresh and check the names.

The request for names alone takes more than 1.5 seconds, and I've lost count of how many times I realized the opponent I was looking for was one of the six displayed after I had clicked refresh.

That was the purpose of the user hash, which would direct all information regarding a single user through the same set of virtual nodes reliably, meaning that cache although distributed, for the purposes of a single player is not, meaning you avoid all of the nastiness regarding sharing the cache between nodes. But yes, having a cache at all is not necessary, and adds A LOT of complexity for arguably negligible gain. Sorry I'm a bit of a performance junky when it comes to software development. And it was a mistake to use the words distributed, cache, and simple in the same post as one another... or even same thread for that matter =0. Crap! I just did it again, disregard that.