> I'd rather Niantic cache more to reduce load on servers.

While it is always possible that they just massively suck at infrastructure, I suspect that cheating is the issue preventing more caching.

By keeping everything on their servers, the types of cheating you have to police are massively reduced.

And people who play Pokemon will do ANYTHING to catch 'em all.

They keep their 3D models of individual Pokemon including their animations on a CDN and don't perform any caching on the models. I suspect these change infrequently enough that they could be built into the app itself and save a significant amount of data.

Another user has already mentioned they don't attempt to cache image or textual information about Pokestops. Pokestops for most people are pretty recurring. This probably consume less information than the models but is also likely to be pretty static information.

It looks like the Pokemon Go architecture is largely cannibalised from Ingress. Pokestops are warmed-over Ingress Portals (same locations, same names, same photos). In Ingress, portals are much more dynamic - things that have happened in the last few seconds to a specific portal matter. From that point of view it's not surprising that Pokestops are uncached; I wouldn't be surprised if they added caching in a future release.

If you were Niantic, and expecting Pokemon Go to be roughly as popular as Ingress, would you bother going to the effort of adding a caching layer when you could not, and expend your efforts on the front end and content, and get the release out sooner?

> If you were Niantic, and expecting Pokemon Go to be roughly as popular as Ingress, would you bother going to the effort of adding a caching layer when you could not, and expend your efforts on the front end and content, and get the release out sooner?

Because Ingress wasn't reliable either, and this way Pokémon Go has an opinion of being playable mostly when everyone else is asleep. It's only this week that I can actually run it somewhat reliably after work...

Speaking of Ingress portals - there were not much more dynamic than Pokéstops are (given that you can drop "Pokéstop modules" on them, which affect all players). This was my complaint against Ingress too - while portal state should be redownloaded continuously, the visual/information data changes infrequently to never. The name, the photo. The stuff you actually need to have to display portal details. Similarly Pokéstops. That kind of data should absolutely be cached. It cannot be used for cheating, and caching it is like elementary engineering.

>They keep their 3D models of individual Pokemon including their animations on a CDN and don't perform any caching on the models

Could you provide a source for this? I did some Googling but could not find any information supporting this.

I definitely agree on the Pokestop data, but I find it hard to believe that models and animations are not assets included in the app file.

You can't find any info because it is completely false. As a Unity game all of the assets are stored in the asset bundle. The game contains ~60mb of assets. The only data the game fetches are the realtime map data and even those are cached internally.

This isn't entirely true. I've used a package from the asset store that let you dynamically load .fbx files from a server.

I dunno - the lookup tables for stats + animations + attacks are sent via protobuf, but the 3D models themselves should be in the app.

that or enable fast most like gold and silver version had, that skipped all that jazz, which in turn should also save battery life by not rendering / downloading any of that stuff.

The pokestop images don't appear to be cached -- they come up blank when touched even though you've been there a dozen times before.

There's a good chance players will click on the same pokestops again and again, so caching even just the last 50 one would be helpful.

I agree, my browser is still in the #1 spot for data usage. I'd consider myself a power user, but still I've had Pokemon Go open a lot (an am level 23) so it's pretty interesting that more data isn't being used.

I'm curious they seem to have so many problems, given that at it's heart the game is rather .. decentralized.

They have access to this vast swath of cloud technology and a few Moores law iterations to boot yet they seem to perform worse than even WoW did on launch, with a game that is extremely forgiving to latency.

Indeed. In addition to this their outages have, over the past few days, been very predictable. There is one happening right now [1], and one happened at the same time yesterday and the day before. As far as I can tell that should make it easy to decide when they should deploy new servers to handle load better.

1 - https://pokemongostatus.org

Yup. The load usually starts to happen when kids leave school, and then the servers blow up when adults leave work. Until this week, the game literally stopped working for me every day at 17:00.

1. They reused architecture (and possibly infrastructure) from an existing game, which has a different mechanic and different usage patterns. 2. It's massively more popular than they originally anticipated.

Everything I've seen based on previous outages, and rumours, seems to indicate it's probably a player data/authentication problem rather than the parts that are easily distributed (pokemon generation, image serving for pokestops, etc.). During a number of outages you'd be able to keep playing for a time iff you were already online and playing, at least according to some reports.

I'd love to see actual postmortems from them but I doubt we will since they've said nothing at all so far. But the authentication could easily be a problem that they're using both their own service and google for providing authentication. Since they go down each time a new region is released it would make sense that they're getting hit with lots of account creation and google API hits, the things that are likely to be the worst for scaling, since google will rate limit most clients (though I'd think they could get something worked out since it's all real traffic). Along with that, their own authentication server has gone down near release (pokemon trainer accounts) while the google one was working, so they probably have had to throw servers at that and weren't expecting to.

I'd also expect a lot of the load to be related to doing lots of geospatial queries, but I doubt they planned that badly since they had experience with ingress. I think it'd be related to the nearby pokemon feature that they've had broken since shortly after launch.

There's definitely questions (e.g. why did nearby pokemon break the way it has?) about the particular bugs that people see that make me wonder how they've handled things but i suspect we'll never know since the answers are going to whatever secret sauce they've done to handle this kind of game.