Hacker News Reader

Comment by filleokus | Hacker News Reader

Compared to something like Slack or Office 365 products it could as well be carved in stone. I'm guessing 99+ % of requests are non-authenticated, the data is easy to cache and freshness (on the timescale of minutes or hours) is almost worthless.

Even something as simple as HN probably have much much lower value of "usefulness if the service is served completely static from caches", due to upvotes and comments. If the front-page and comments stayed static both during breakfast and lunch, my WFH routine would sadly be impacted...

View on HN

> freshness (on the timescale of minutes or hours) is almost worthless.

On the contrary, users get very angry if stuff isn't fresh.

Someone changes trump article to say he is a poopy head. If that gets fixed in 2 seconds, no big deal. If that gets cached, and the edit to fix it doesnt hit the caches for a couple hours, wikipedia is now the top story on CNN.

Generally wikipedia caches are expected to be updated within seconds or minutes at most.

Okay, that's fair, my view was too simplistic. But still, Wikipedia could probably get away with days of 1-5 minute cache refreshes if it was required? Especially if some banner informed users about it or something.

I think my larger points still stand. In comparison, almost all other services at the scale of wikipedia have critical almost-realtime components, and is almost useless without the possibility to authenticate users (which can't really be cached).

Not saying that the people who manage to keep Wikipedia so stable are doing an easy task, just that it's very different from almost all other things on the web.

I've sometimes heard wikipedia described as a "large scale static site plus a medium scale social network". The caching is a bit more complex than a naive static site due to churn rate and freshness requirements, but fundamentally you are right, without frontend varnish caching, wikipedia would be very different in terms of hosting requirements and scaling complexity.

I'm also wondering if the caching strategy they are using is a naive one (ie: cache is valid for a fix duration, like 5 minutes) or if it's a more active one (like stakeoverflow), with cache in validations each time a page is modified/commented on.

There is cache invalidation each time a page (or one of its dependencies. Pages depend on lots of other pages) is modified.

Assuming things havent changed, each varnish server listens for purges via multicast udp.

Purges have been migrated to kafka as a mean of transport, at long last. So now if a purging daemon crashes, purge requests are not lost.

You can see per-server stats on purges happening here:

https://grafana.wikimedia.org/d/RvscY1CZk/purged?orgId=1

Reply on news.ycombinator.com