Regarding the "macro" caching of anonymously viewed pages.

After some searching I think the most robust approach is to set up one or more reverse proxies to handle the bots and SEO.

They can cache all static requests locally and rules can check the cookies and relay logged in users to the upstream servers for dynamic content.

Cache management is also included, nginx for instance can receive "purge" requests of cached urls remotely via web requests, which means those proxies don't even need to be on the same box.

And this doesn't even need to be triggered directly from inside the Everything engine.

Running an external cronjob checking for new nodes via XML ticker (like every x minutes) could be implemented immediately and update all proxies. ¹

So no need to patch anything inside the monastery except server settings.

I think "Micro caching" to speed up the engine's most frequent evals and queries is also possible but would certainly require patching the Everything codebase. But this would require good benchmarking and is less relevant for our "bot war".

¹) of course querying the DB directly for new and updated nodes and votes would be even better.

My point is to show how flexible and available this strategy would be while immediately shielding off our engines from DNS attacks.