4 ms·
So, you’ve got a static-ish page, a Ruby server, Postgres and NGINX. The page both POSTs and GETs comments from the backend via an Ajax calls. All very conventi
by yashap 4y ago
So, you’ve got a static-ish page, a Ruby server, Postgres and NGINX. The page both POSTs and GETs comments from the backend via an Ajax calls. All very conventional, but then you’re worried about traffic spikes, and to deal with that, the comments on the server are stored in pre-generated HTML files, updated by some wild PG triggers setup, and served up by NGINX. IMO you could go way more traditional, with the same result.
Worried that Postgres will tip over? Just read from the DB, but cache the results in memory with a short TTL on your Ruby server.
Or, if you’re worried about not just Postgres, but also your Ruby server getting overloaded, just go with a fully server rendered page, and cache the whole page. Could use NGNIX cache, as you’re already using NGINX, or a CDN, or Varnish, whatever. No JS loaded comments at all.
Either way, caching should be able to get you tonnes of scalability, easily avoid
hug of death, without resorting to PG triggers calling a Ruby server that writes files to disk.
With that being said, this approach works too, and if it’s just a personal page with you as the only dev, you understand it, so it’s all good. But I’d certainly avoid this approach at a company, largely because it’s unusual and will take new devs longer to wrap their heads around.
- thom 4y agoThe 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.