I’m often asked how we write scalable web applications. I’ve boiled down the long list of factors we consider to the following four key features. It isn’t an exhaustive list, but any web app missing any of these is at best an unknown, and at worst heading for trouble!
#1 Multitiered Application Architecture
Writing your application in multiple tiers allows for horizontal scaling. For example, a three tier application will typically have a backend data store layer, a business logic / application layer, and a front end layer serving the data out to your web page, application, or mobile app – or all three! These tiers should be independent of each other, so that when the database tier starts creaking, you can add a couple of hosts to that tier, replicate your database horizontally onto those hosts, and triple the capacity of the data layer. If it was the application layer, add the boxes there and run a few more instances of the application. If your application is evenly utilised, add a box to each tier to increase your capacity.
The gold standard here is to achieve linear horizontal scaling. Add one new hardware box to any of your application layers, and increase the capacity of that layer by one unit. This approach makes sure you can scale from a two box cluster, right up to a three thousand box server farm. Factor in the increasing power of hardware over time for a given cost, and you can achieve greater than linear scaling.
#2 A Capacity Plan
Your beautifully architected app won’t scale at all unless you have hardware (or cloud capacity) to scale it onto. Ideally, you’re ready for increasing capacity. You know where the budget’s coming from, you know where the capacity will be introduced, you know your cloud host can bring it online, or your data-centre can rack and cable it within two days. When you have your capacity plan, you’re ready to satisfy the increased needs of your application. Feature #4 will help you predict this need, and feature #3 will help you get it up to speed once it’s online.
#3 Architected for Easy Deployment
The easier it is to bring up an element in your system, the quicker and cheaper it is to add those new boxes. If, for instance, you’re running Ubuntu and you’ve packaged your application up into a private apt-get repository, then installation is as easy as “sudo apt-get install my-web-app” or “sudo apt-get install my-database-schema”. The installation process will initiate and launch the service, and you have a one step install, that any competent Linux user can perform.
#4 Monitoring
How do you know when your application needs to scale up or down? Because analysis of your historical monitoring data and identification of the trends it shows tells you! Basic monitoring tells you how loaded each piece of hardware in your infrastructure is. So you can see that your database host is holding your application back. Better monitoring shows you how each tier in your application is performing. So you can see that your application tier is only using 10% of the capacity of the blades it’s running on, while your front end web servers are maxed out. Migrate some of those blades to your web severs, and you’ve just increased the capacity of your application without buying any new hardware.
Conclusion
There are a tonne of other factors to writing a scalable web application. For example, graceful degradation, knowing when to make an API idempotent, knowing when to vertically scale, knowing whether to shard your database, or use a master / slave pattern, and a lot of other things. However, if you’ve got the four points above covered, you’re off to a great start.
We also have further information in our podcast – ‘How To Scale Your Online Application‘.