Scaling Strategy

Hi,

This is a subject that’s been dealt with many times here and in other forums, but I wanted to bring it up again and see if I can get a fresh perspective.

I’m starting a multisite network (a specialized hosting service) that I expect to do well. And I want to plan the best scaling strategy that will allow me to start with a reasonable amount of gear now (e.g., one or two dedicated servers), but grow with minimal headache as needed.

The strategies I’m looking at are:

#1: Putting Everything in One Basket

The entire network would be under one domain, and would scale as needed. The question is how it would scale. I assume I could start on one or two servers now, then span the system across multiple servers later via Multi-DB and a distributed file system for uploads. The downside is that, as mentioned, everything would be in one basket. A failure on one server could cause problems for the whole network.

So, if I go with this strategy, I’d certainly appreciate any recommendations on the best way to grow the system when it’s time.

#2: Standalone Mini-Networks

With this strategy, when the original network gets to a predetermined capacity, I’d bring another one online under a different domain name. The domain names are somewhat arbitrary, since most users will probably map their own domains to their sites anyway. So users probably won’t care whether they’re signing up as mysite.bigbloghostingservice.com or mysite.bighostingcompany.com or whatever.

A variant of this strategy would be to start with two or more networks, each using their own dedicated server, to give people a choice of domains from the start. This would essentially create a similar situation to using the multi-domain plugin offered here, except that users would actually be choosing between different networks (unbeknownst to them).

The advantage of this strategy is NOT putting all the eggs in one basket. Instead of growing one big network and having the related growing pains, this strategy would just consist of creating a new network. If one network fails, only the users on that network are affected.

The disadvantage is that I’ll have to install themes, plugins and other modifications multiple times instead of once, but I think the extra work probably wouldn’t be any more than the efforts that would be needed to manage the “single basket” strategy above.

#3: Hybrid Combination of #1 and #2

This approach would consist of separate networks…but when each one outgrows its server (or comes close to it), that network is grown into a small cluster. For example, a single-server network might be split off into three servers (database, web, file uploads). And we’d leave it there. Then, when each cluster gets as big as we want it, we bring another new network online.

The advantages of this strategy would be limiting the number of networks (instead of putting a new small one online whenever we need more), while limiting the headaches and risk of putting everything in one huge basket. This would be several smaller baskets, but not lots of tiny ones.

Am I on the right track or barking up the wrong tree entirely? (Woof.) Any thoughts would be greatly appreciated.

Thanks,

Mark