Because we invalidate some SSDB keys in various cases, for ex: like old code stats data incoming, renaming a project, etc.
Http proxies with etag seem like a good public-facing cache option, but our caching is internal to our DigitalOcean servers. Here's more info on our infra, which might help with our decision:
Consider using opaque symbols for your object/cache identifiers instead of using meaningful literals. That way, you can simply update the identifier mapping (Project A cache prefix moves from ajsdf09yu8sbvoihjasdg -> klajnsdg9fasf8avby), and the old values will naturally be evicted from the cache as they become less frequently accessed.
In my experience, having to perform cache invalidation is usually a sign of design immaturity. Senior engineers have been through this trial before :-)
nginx has proxy_cache_purge (1), but I agree that nginx doesn't expose a particularly good API around its cache. Plus, the awkwardness of doing disk IO from OpenResty (unless this has been improved), is a drag.
Maybe this is something envoy or the newer breads do better.
Http proxies with etag seem like a good public-facing cache option, but our caching is internal to our DigitalOcean servers. Here's more info on our infra, which might help with our decision:
https://wakatime.com/blog/46-latency-of-digitalocean-spaces-...