3 ms·
The approach in the article is functionally different though, in that the cache is always immediately invalidated when a new comment comes in. So it’s not the s
by thom 4y ago
The approach in the article is functionally different though, in that the cache is always immediately invalidated when a new comment comes in. So it’s not the same result as using a cache with a TTL.
- 411111111111111 4y agoYou can always set a super short TTL like 15s or even 1s. It's still going to make scaling a non-issue like that and at some point the caching will be fresher then the html generation, as that needs to be done too (and read after by the http server). It's fun to make architecture like in the article though, I'm guilty of it as well with previous hobby projects
- yashap 4y agoOP’s approach has fast cache updates, but it’s still eventually consistent. Like, the whole flow of PG trigger, handled by Ruby server, then writing to a file, that happens outside the flow of POST comments, and could sometimes finish after POST comments returns to the caller. Also, with my suggestions, you can cache invalidate too, if a short TTL isn’t good enough. Based on writing files to local disk, it seems like a “single server” scenario, so invalidating the in-memory cache on POST comments is dead simple, and can be truly immediately consistent. Likewise, for full page caching, if using Varnish as a cache, Varnish lets you invalidate easily too. NGINX and CDNs don’t (generally), but if a short TTL isn’t enough, and you need instant invalidation on new comments, then just go in-memory cache or Varnish.