Scaling: Don’t become a victim of your own success

A common issue with online startups is that they only start thinking about scalability once their site goes down. Many of the big startups also experience this phenomenon (e.g Twitter, Tumbler). They take note and spring into action only once the issue has occurred, which almost always has a detrimental effect on the user experience.

Unexepected traffic spikes that could be generated by something as simple as a post on a reputable tech news site can bring your site to its knees almost instantaneously. In that brief moment of fame, your site crashes and all those potential new readers/customers/fans who are coming to have a first look at you, are lost.

Symptoms like slow page load times, regular crashing, errors and downtime could be telling you that your US$8 shared hosting or single instance VPS server just won’t cut it anymore. Perhaps even after months of normal usage, with the slightest increase here and there, everything grinds to a crawl. Why? There are many potential reasons. Close monitoring and good communication with your service provider can help.

It’s vital to keep checking the code. A recent discussion with a customer about his site revealed that the core code is 5 years old, and that it needed to be restarted almost daily to maintain some semblance of uptime. Although it’s possible to run like this (and many startups do whilst they frantically try to build fixes), it’s much easier to scale with the correct architecture design (both software and hardware) from the start.

There comes a point when throwing more hardware at the problem yields an ever diminishing marginal return. Every aspect of the application needs to be inspected for bottlenecks, even the static content delivery.

Some important points to remember about scaling:

1. Changing your app/site to handle high volumes can be difficult if you haven’t planned for it upfront.
2. Most junior/mid level developers don’t know their architecture is utterly inadequate to go beyond one customer a minute, and have no clue how to fix it.
3. Scaling is not something you can just easily ‘buy-in’ later, possible but difficult.
4. Good application architecture is about creating scalability through architecture design, application optimisation and data optimisation. It’s not only about throwing more hardware at the problem.
5. Scaling out with multiple servers instead of upwards (bigger) with a single server provides you more scalability & redundancy.
6. Caching, proxying and database optimisations are essential.

Either become an expert or hire an expert to consult on your scaling issues, it can make or break your business.

Customers are becoming increasingly intolerant of slow load times and frequent downtime.

Never forget that sites like Amazon and Google meaure a sites slow loadtime in lost revenue potential. After all, you only get one chance to make a good first impression.