I’ve seen it before. The demo version of your web app has most of the key features and conveys the story that you want your management (or investors) to hear. Once you get the go-ahead, it’s a sprint to the launch without looking back. The rub is that you didn’t actually have a scalable design for the app – you didn’t need it for the demo. Now, several months in, with traffic growing, performance dropping, and most of your user ratings at two out of five, it’s not the best time for re-engineering.
A better approach is to design for scalability – not in the initial demo: that’s not it’s purpose – but when you start planning for launch. Design for scalability is an iterative, multi-step process that starts with an architecture assessment, workload model, and resource consumption estimation. You instrument your code to capture key performance indicators or KPIs, receive alerts about anomalies, and review trend data weekly. You can’t anticipate every problem, but you have done enough work to anticipate most of the them, and to be able to respond in a timely fashion.
The fact that more and more apps are built using elastic cloud technologies eliminates many of the hard physical capacity limits that web applications used to experience. A RESTful design also helps with scalability. But there are still performance bottlenecks and failure modes that can cause problems if you don’t know they are there, and plan for them. A simple definition of a scalable design is one where you add resources linearly with traffic growth. Following best practices for capacity and performance management are essential to a scalable design, whether you’re in an Internet start-up or building healthcare.gov.