Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Cache invalidation is much easier with SSDB than Nginx or Varnish. Http proxies are good for public facing uses but not a good use case here.


How do you figure? Http proxies support various common cache invalidation strategies such as hash-TTL and ETags


ETags are not cache invalidation. ETags are a way for a client to validate the cache in the client, while cache invalidation for a http proxy would involve telling the proxy that it should discard a cached file.

---

Basically:

cache validation: Check if a file matches a cached version

cache invalidation: Preemptively tell a cache to discard a cached file

---

For example:

Client A requests file X. Proxy caches file X.

File X changes in the upstream.

Client B requests file X. Proxy does not know the file changed upstream, so it sends a stale version.

---

In this case either the proxy needs to revalidate each request with upstream (which is expensive) or we need some way to tell the proxy that it should discard it's cache for file X since it has changed.

Nginx plus supports this but the free version does not: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr...


For Varnish PURGE seems the most sensible:

https://book.varnish-software.com/4.0/chapters/Cache_Invalid...

I think I'll have to look into this to see if we can get away with document/blob cache in one of our solutions actually. I've resisted add-in Varnish in the mix, but it might be time to reconsider.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: