Thinking about Large Scaling Before You Need it

Thinking about Large Scaling Before You Need it

John Smith is a hardworking chap. From nothing, he’s built his digital marketing startup and now he has about 4,000 enthusiastic users. Considering that he just achieved all these in such a short while, he’s very proud of himself. His business card is embellished with the tag, “CEO”, a title he’s well-deserving of.

John’s life was all fine and well until one day, he wakes up and realizes that his servers are down. He calls his chief engineer, his only engineer, to find out if this is a DDoS attack, but it’s not. John continued, “Obviously, it has to be an error because the apparent reason for the failure is “system overload”. And system overload can only occur when about a million people are trying to access the server at a time.” Or are they?

Eventually, John loses a good percentage of the 1 million users who tried to patronize him after a renowned celebrity mentioned his company on live TV. He also disappoints the loyal 4,000.

John’s dilemma might not be a typical example of what startups face on a daily basis, however, it is not unlikely. Facebook launched in 2004 and in 10 months, a young man with no management experience had 1 million users. If you think such a remarkable achievement was in the past, Uber, Spotify, Tumblr, Dropbox, and Kickstarter prove you wrong.

However, a number of startups are barely capable of managing such a growth spurt. In fact, it is usually the reason why startups fail- inability to plan for the future. According to Mike Krieger of Instagram, scaling an app can be likened to replacing the components of a car as it is driving at 100 mph. however, this can be avoided. You can effectively plan and mitigate any challenge that comes up in the course of scaling.

How do you do it? Glad you asked!

There are two approaches to it;

  1. A phased development model is followed and the company starts with a particular pool of target audience. As popularity increases, it is then expanded to other spheres.
  2. The second involves using cross-platform app development frameworks which support scalability such as PhoneGap or Titanum to create hybrid apps. In just a single environment, code reusability, cloud features, and optimum management are part of the benefits.

 Now, whichever approach you decide to take, there are several considerations which you will be faced with. This post guides you on the path to tread with cogent reasons.

1.Scaling Out or Scaling Up

When you scale up, you migrate your server to a stronger and more efficient computing system and you get more computing power and memory. Expanding means that you change again to a more powerful system.

Scaling out, however, means you’re running your operation on a number of computer systems. When you expand, you simply add new computers. This is the better option as it offers more potential for infinite scalability without incurring an exorbitant cost.

2.Single Server or Multi-Server

You’ll hardly see any startup not using a single server architecture for their MVP. This architecture, however, is such a big risk. It means that the loss of data might be irredeemable. Although a multi-server architecture is more complicated, it improves productivity greatly. You can also employ a load balancer to track traffic and distribute request automatically.

3.Cloud or No-Cloud

If you’ve been in the system for long, you’ll know that this is a no-brainer. A cloud architecture is, perhaps, the best option to ensure scalability. We have a more detailed blog on the merits of Cloud for your Business. Click here.

4.Microservices Architecture

Some of the largest customer-servicing companies in the world such as Twitter and Amazon have adopted this model. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables the easy re-use of code on manifold platforms and applications.

Represented below as an example is a typical microservices architecture for an IoT based product application

 

5.Database and Server Architecture

In your database architecture, are the queries optimized? While indexing might enhance the response time, it is important to maintain balance. Also, you might consider returning cached versions to queries after a set time. This will reduce the load on the server. Finally, ensure that you start out with the right partners. Go for reliability and cost-effectiveness, every other thing will fall in line.

We at Biztruss have been supporting applications with their scaling architecture using our unique blend of proprietary frameworks and tested methodology. We have recently implemented a very offbeat scalability model for an IoT application based in Belgium, which is a very interesting case study we’d love to share with you. We would be happy to help you analyze your website or application for scalability so you can achieve the scaling that could help you focus on the possibility of bringing in a million users to your site.

Conclusion

Your app is relevant, it is functional, and most importantly, it has a role to play. You don’t want to be another John Smith or go through his ordeal. You don’t want to deny a group of teeming potential customers the opportunity to enjoy your product. Think about scaling your product even before you need to.

We’re not half done talking about this amazing area which only stands to grow further by many leaps and bounds, so be sure there’s another blog that’s coming your way from our hot press

Biztruss Newsleter Liked this Article?

Sign up for our biweekly updates on Digital Technology, Marketing and Strategy tips.

​All emails ​include an unsubscribe link. You ​may opt-out at any time. ​
See our privacy policy.