Keep a historical redis key that gets updated with latest rank information

[Sciguymjm]

If the rank API is down and the current key expired, use that information instead of fetching anew.

[kcolton]

The approach to this I prefer is having 1 key for marking is the rank data is fresh with the short expiry time, and then a key with a long expiry for the data itself.

The logic gets a little hairy dealing with the cases like: first fetch failing, but thats what unit tests are for.

• ${rank_data_key}: Stores serialized rank data - long expiration time or let LRU policy handle eviction
• ${rank_data_key}:fresh: Binary marker for if data is fresh - short expiration time; if doesn't exist, attempt fetch fresh data.

Keeps from having to store the full data twice. (not a big deal for small data structures, but a more elegant pattern in general me thinks)

[Sciguymjm]

Makes sense. I suppose I didn't really think this through ;)