Whenever we plan a new software project, there's always that million dollar question: how do I make sure I'll have a scalable web application?
Unfortunately, there's no simple answer to this question. To get the right answer, we first need to address many additional questions and, more often than not, the long term answers aren't known at the initial stages of the project.
What does scalable means?
Does it mean the system needs to support an hundred active users? One thousand? A million? Or does it simply mean building a system that can handle whatever number of users we'll have in the next 10 years?
Yes, it's the last one and it's certainly possible to plan and develop such a system.
In the most complex case possible, we can design a system to handle the entire world population logged in at the same time, but will it take the same effort to implement such a system, when compared to an application that'll handle only 10.000 active users?
The answer is simple here, it won't.
Let's imagine we want to design and build a car. It'll surely take a lot more engineering hours to design a car that can run at 200 km/h, than another that can run at 350 km/h. The challenges of designing a city car are way more harder than designing a F1.
Scale is always tied to boundaries and a price tag and most of the time it's an iterative process. Software applications behave according to the Pareto principle: 80% of the time is spent on 20% of the code. And we, developers, need to have the application up and running to clearly understand where that 20% lies.
Then we need to plan, optimize, observe, plan, optimize, observe... There's no point of optimizing the 80% before the most used 20%. We should aim for the low hanging fruits first.
Optimizing your work
There's a certain degree of work that we can do in advance to make sure that scaling costs are as low as possible. Just like when we're designing a car, we already know curved shapes have a better performance on wind tunnels than sharp corners, and there's certainly no need to reinvent the wheel.
So here are some rules that you can follow early on in your development cycle to lower scalability costs:
1 - Use frameworks such as Ruby on Rails or products such as Wordpress, rather than a custom made framework built on top of PHP or another language. Widely adopted frameworks and products have good, tested practices and strong communities to help you deal with common scalability issues.
2 - Sacrifice data coherence if possible. If your team will not be writing critical software for financial or life support systems, consider using 'No SQL' data stores like MongoDB or Redis. These data stores have lesser guarantees in maintaining data coherence, but are easier to scale.
3 - Have a great development team. Experience matters, and past performance too. Make sure your CTO, developers and contractors know what they're building. It's a big plus if they've done similar projects before, with good results. They should be asking the questions above every time scalability comes to the table. If they simply say 'yeah, yeah, our system is scalable' - you should start looking for other options.
Building a scalable web app seems complicated, because, well, it is. There are good practices we can adopt, in order to lower the price to pay for scaling our system in the near feature, but the bottom line is:
There's no magic formula regarding scalable software systems.