uber-archive / backbone-api-client-redis Goto Github PK

Internally, we use twemproxy which does not support keys which renders our current deletion pattern useless.

https://github.com/twitter/twemproxy/blob/v0.3.0/notes/redis.md

Some possible solutions:

• Maintain a list of keys that relate to a collection (maybe via a hash?)
• Move to a hash (e.g. hget/hset) and figure out if we can expire there (pretty sure no)

While request-redis-cache is great, it is a little too naive. I would love to support stale-fresh-cache which is intended to work via:

Let's work with an example TTL (fresh = 30 minutes, stale = 60 minutes).

If we have no cached information, get it and cache it for 60 minutes.

If there is cached information, send back whatever we have.

In addition, check the TTL. If the TTL is over 30 minutes (e.g. the cache has turned stale), fetch the information in the background and update our cache.

The benefit to this mechanism is it prevents completely running out of data to serve without sacrificing performance. Additionally, it guarantees the data will expire at some point. However, it is still possible to cache stampede =/

Currently, it is a little annoying that we more/less lock in callApiClient functionality before allowing caching mixin. Should we be doing this and is there a better way (e.g. via sync overrides)?

For reference, we are currently structuring it this way to pick up changes from adjustApiClientOptions which could affect parameters and thus the hash for the request. We want the hash to be as sensitive to what is actually sent out/important as possible.

Currently, we only cache read responses and invalidate on everything else. However, some server support sending back the resource upon create/update. As a result, we should cache/serve that data.

Unfortunately, we guarantee requests are stored against the hash of their request options. As a result, it is impossible for us to predict what save data would line up with, if at all.

Additionally, this hash is used to switch between server upgrades easily (e.g. new attributes on request options).

Please discuss possible options in this thread.

Sometimes, actions at one-off endpoints affect your data. While this is non-atomic and disgusting itself, it happens. To make sure we keep our cache accurate at these points, we should expose the cache deletion logic from callApiClient as clearCache.

clearCache(method, options, cb);