Going from One to a Million Users
Web development is a profession that has one of the lowest barriers to entry that I can think of. It requires a computer, an Internet connection, and time. While some may consider these prerequisites too high for many people on the planet less fortunate than us (and indeed, they would be right), programs such as OLPC are attempting to bridge this gap.
In addition to a low barrier to entry, a somewhat unfortunate side-effect of the current ecosystem is that many people (especially those new to web development) are at a loss when it comes to scaling their app to accommodate an influx of traffic and users. Often, these problems are relegated to people with fancy titles such as Systems Architect or Senior Architect, and with good reason; this stuff is difficult. Very difficult. It takes quite a bit of blood, sweat, and sleepless nights to understand just how hard of a problem this can be.
Nonetheless, a superficial understanding of the challenges in scaling a web app can be useful to developers who wish to progress further in their career and to better understand the trade-offs that are made during the lifetime of an app.
Let's look at a broad and general overview of how a typical app might grow, what problems might arise, and some general-purpose solutions to these problems.
Money does solve problems
You might think that there's something inherently cool or fun about maintaining all of the disparate servers and services that your app requiresa€‰-a€‰and you might actually enjoy it, at least for a little while. After the initial honeymoon phase wears off, however, the hard facts start to set in. Every minute that you spend fiddling and maintaining your architecture is a minute that could be spent improving some facet of your app that could benefit your users in a much more direct way.
As is often the case, the simplest (and sometimes most cost-effective) solution is to simply throw money at the problem. With the recent affluence of general platforms as a service (PaaS) such as Heroku, Engine Yard, and even language-specific ones like Gondor.io, the need for a full-time operations person on staff for a small- to mid-sized web app has decreased dramatically.
Take it from someone that has been paged at two o'clock in the morning in a foreign country when servers go down due to network issues, and your Internet connection amounts to a hotel using an AOL CD they found in the trash; if you can pay someone else to have that problem, do it.
Every problem you pay someone else to have is time that you can use to focus on what makes your app special.
If you're like 99% of the web sites in the wild, you most likely started with a single server for running your app. Or, you might even have started on some form of shared hosting. There's nothing wrong with that; we've all been there.
There comes a time when that single host isn't able to keep up with the demands of your appa€‰-a€‰your database grows too big, you become memory or IO bound (depending on your app and your service stack), or you're not able to attain whatever response time or throughput goals that you've set for yourself. This might be stressful, but remember, problems of scale are generally good problems to have. Most apps struggle to hold on to a few hundred users, let alone have the privilege of needing architectural changes to scale upwards.
Your go-to solution at this point should be one that minimizes the changes in your procedures, development time, and complexity of the system and app architecture. For most situations, this means getting a more powerful machine. If you're on some sort of virtualized hardware like Linode or Amazon Web Services, then this is simply a matter of a few clicks in their respsective web consoles, and a few minutes of downtime. While the latter might not be desirable, generally, it is tolerable for your users if handled correctly.
Considering the various memory, processor, and disk configurations available from virtualized or bare-metal providers, this very simplistic approach of making your servers more powerful (also known as vertically scaling) can get you quite far.
If your user base continues to grow, vertical scaling will only get you so far. The next step is to separate out your system architecture by broad components and services.
The obvious choice for most is to separate the web server from the database. In doing so, an additional layer of complexity and an inherent network overhead is introduced. However, yo
Truncated by Planet PHP, read more at the original (another 7339 bytes)