Hello,
If we get accurate statistics on what kinds of processes these are and what quantity of resources they consume, we might be able to integrate these considerations into the simulation environment we'll be using to evaluate various architechtures for distributed hosting.
We're doing some of this action for links processing, where delays can be tolerated, but that's more for serializing pagelinks load. Though nature of wikis does not allow lags for most operations - if edits were async (I'd love if they could be..), multiple people would be editing same pages and of course, getting conflicts. Async communication for conflict resolution would be somewhat difficult. And other actions, such as diffs, views, whatever, all need to be synchronized. Of course, distributed caching helps a lot, and our aim should be better efficiency of it, but still, we've got to be in sync.
As for distribution, I'd like to see some of application synchronization primitives (like message cache state, db server lag, etc) being pushed to app servers rather than pulled from db/memcache. But that's already fighting miliseconds :)
As for architecture, there're not that many low hanging fruits at the moment that would be easy to solve by distribution. If anyone sees it otherwise, please tell :)
Domas