This is something I’ve always wondered about. I understand that horizontal scaling is about adding more machines into the mix. But I can think of two approaches to this. Suppose I have 20 servers I want to use (plus a database). I can:
- Make all 20 servers run as application servers.
- Make different servers do different parts of a task. For instance, have one set of servers handle the request, then another set to apply business logic, and then another to make the database call.
Number 1 seems to be more common and easier to understand, but number 2 seems to be considered “best practice” (as it’s mostly an n-tier architecture). How does one choose between these two models? And what are the pros and cons of each approach?
It depends on the task, and what would be your bottlenecks.
Almost without exception, you’re going to need at least two kinds of server: 1) Application and 2) Database. If you distribute the application servers, you still need to synchronize data between them, making one of those servers (or a separate server) be your database server.
If you know the database will not be hit with much traffic (e.g.: you are running a live chat-based site, and not much data is permanently stored or synchronized) then the choice of making nothing but application servers might be fine.
Choice #2 is better, however, for a majority of sites, especially if you don’t know in advance which servers will become bottlenecks. If you don’t allow for each server type to scale, then you’ll be stuck having to rewrite source code during unexpected growth spurts. Then you’ll have to make difficult decisions like “Which features should we disable so the site can still function while we work on scaling?”
Honestly, though, I wouldn’t spend too much time worrying about scalability. Once you reach a point where your server loads are becoming too high, you will be able to afford some source rewrites. Either through newly discovered sources of funding, or through direct profits off the site. Case in point: Twitter is still doing great.