Any discussion about the architecture of a software project leads to arguments over the best way to achieve scalability. Essentially, it comes down to finding a happy medium between the time required to develop a scalable architecture and how scalable that architecture will be.

On one theoretical extreme, we could build a simple prototype of our software over the weekend, capable of supporting 100 users. Once we pass 100 users, we would have to restructure the architecture. On the other side, we could spend a year building rock solid software, capable of supporting 100 million users.

This is where the idea of Just-In-Time (JIT) scaling comes in. Once you’ve reached a certain amount of users on the first iteration, you can afford to spend more time developing the next iteration. Scaling can be done through iterations. Avoid premature optimization.

Facebook first ran on PHP and Twitter ran on Rails. Stackoverflow used C#. Although the choices of language or database are the most often questioned at the initial stage, these are not very important questions. Build with the stack that you know. Reaching the limits of the stack used in the first iteration is A Good Problem to have.

Even before you reach the limits of iteration one, you can start development on a more robust, scalable architecture. By always building ”just enough”, you can minimize development time while staying ahead of the scalability curve. Keep in mind that, no matter what scripting language the prototype was built in, once your software scales to hundreds of thousands of users, you will likely be running on heavily optimized low-level code.

Of course, there’s no need to completely rewrite your entire codebase every time your growth multiplies. By modularizing development of different components, and by using internal APIs and queues, you can scale distinct parts of the software independently. These design questions are the questions that are important to ask.