Hehe, I'm not ignoring you, I've just been busy what with E3 recently behind us now ;).
The general architecture behind our most troublesome (logical) server is that there are a number of "sectors" that run independent of each other physically. Under most circumstances there aren't more than 10 players in each of these instances, but the physics is pretty intense nonetheless, because we're taking more of a "mass carnage" approach than most MMORPGs you might be familiar with... so we have a large enemy AI to Player ratio, and the AI not only has to do tactical/flocking/group AI, but also physics for vehicular or creature movement, pathfinding, weapons targeting, etc. We have an advantage in scalability, since we can always "just add" more physical servers and distribute additional sectors to it, but by the same token we have to handle quite a few players/sectors on each machine to maintain our desired cost-to-user ratios.
The most fundamental question we asked ourselves, then, was the primary threading model. We have DirectPlay running it's own little thread pool, but otherwise, we had to figure out - should we split the work into threads based on task (like AI, Pathfinding, Physics, etc), or by sector (sector 1, sector 2, etc). We reached our conclusion fairly quickly, but I would love to hear any input from the gallery :)
To make things a little more fun, our third-party physics engine *must* kick off that sector's physics at least once every 33 milliseconds or it runs the very high risk of either crashing or "exploding" the physics (producing very abnormal physical results).
-Dale