If you are thinking about scaling a web application or service, congratulations, because you have users that liked you or were curious enough to sign up and stick around! You will of course be acquiring more users shortly. While the trajectory of user growth is unknown, and depends a lot on your usage model (viral social network vs. word-of-mouth individual user service) there are a few things you need to address:
- Capacity – your site will need to handle more concurrent users, signing up users alone can generate a lot of load on the system, even before they get to using the product.
- Reliability – users will want to use the service on their own time. The site needs to be up and running 24 hours with limited maintenance windows.
- Scalability – if users can generate data on your site you will have more data you need to store/retrieve.
If you’re growing too fast a common way to solve #1 and #3 is to throw hardware at the problem. A startup focuses on creating the MVP (minimum viable product), which means the prototype has just enough functionality to add a significant value to the lives of users that convinces them to sign up and use it for awhile. Putting the product out there initially means you’re testing the product/market fit, and as a result you’re unsure of how many user will signup, and what their usage patterns will be . Let’s say you are a cocky and a cheapskate, you know you’ll have users, but you don’t want to solve problems by buying hardware all the time. If you’re cautious you will do the following:
- Start performance tuning and load testing even before releasing the product!
- Create a restricted alpha and beta, which allows you to control the growth rate.
- Measure the adoption rates and usage patterns for your alpha and beta users.
- Use the measured adoption rate to anticipate how many servers you can afford.
- Monitor spikes in adoption due to press releases or other news events. And be ready to re-route traffic (failover) in the event of a server failing.
These are the top 5 ways you can initial think about scaling your app without a whole lot of code re-writes. But there will come a time in which you will need to redo a lot of the prototype’s code base. We’ll save that for another post…
Poornima –
I have recently started reading your blog and I must add it gives a good direction to someone looking to understand the intricacies of a start up.
I agree with the points you have mentioned above.I understand thinking on these lines requires some experience.Is there a book/article you suggest reading to get a better grasp of this topic?
Farhana – first hand experience is the key. I personally haven’t read “Founder at Work” or “Coders at Work”, but I’ve heard that it gives a good recount of the startup experience. You can also go through my reading list to see what I’ve read and whose blogs I keep up with.
Few things you might want to add to your list.
1. Ability to support the product after release.
i.e – ability to add features
ability to hand off development to another engineer with reasonable experience.
ability to hand off to sustainability engineer to fix bugs.
2. Choice of platform I believe is the most critical decision decision you will ever make in product viability in long term. Huge choice of languages makes things extremely difficult.
Avoid non object oriented languages – you can’t build sustainable product.
Avoid bloated platforms even if there are lot of libraries
Use MySQL at all cost for backend storage and front end could be anything that has big community.
3. Document, Document, Document.