Since Mojang disabled skins.minecraft.net API, Chrly doesn't proxy skins if skin not found in data storage.

We investigated current rate limits for Mojang API. From documentation we know that all public APIs are rate limited and currently set at 600 requests per 10 minutes. And it's true for the biggest part of endpoints, but not for UUID -> Profile + Skin/Cape endpoint. For this point there such note as "This has a much stricter rate limit: You can request the same profile once per minute, however you can send as many unique requests as you like". And it's confirmed: we easily performed 19k requests from the one IP for about a minute (Mojang, if it affects you, we are really sorry. You know, it's all for science!).

So here is our new solution.

Chrly must organize some processing queue. In this queue Chrly will send request to Playernames -> UUIDs endpoint to exchange usernames to actual uuids. These requests shouldn't be triggered more than once per second and contain more than 100 nicknames. After uuids received, we can exchange them to textures via UUID -> Profile + Skin/Cape endpoint. This request can be performed without any queue: just as fast as possible.

Data obviously should be cached, but there appear some questions:

• Should we cache username -> textures and always respond it or should we cache username -> uuid and request textures every time to immediately handle textures changes? It's important, 'cause if we will have rps over 100 (at daytime (UTC+3:00) Ely.by have a way more rps), than we will be unable to check all textures and some users will don't have skins.

• Another question is should we use primary storage (Redis) or cache it in the Chrly memory with fixed size and some sort of strategy of repression? Currently, Redis eats about 1.5Gb of memory on our production server and is not going to reduce appetites.

• Third question is how long we should cache it? Should it be hour or a few days?

If someone has any ideas about this stuff, I'd like to hear your opinion.