Imagine your website serves about 10000 users and is running smoothly. Now from nowhere, an influencer blogs/tweet about your website and you start getting more traffic. With so many users accessing the website, it can become unresponsive and may fail. The website starts to run out of memory and computing power.
The same kind of misfortune happened with Vero - a Social media app known as the alternative to Instagram. An unprecedented influx of users made its server crashed which led to a huge downfall in business.
Vero is just one example of a website that failed miserably due to its inability to scale further. There are several others in the line too. For example - Friendster, the simplest social network lost its lead in the race of social networks because of scalability related issues.
Scalability on the website is one such challenge that might spoil a thousand hours of hard-work of your development team in one single second.
We reached out to 25 experts for their advice to build scalable-web apps and this article is an excerpt from what few of them have to say on building scalable web apps. Let’s kick things off with Tip#1.
Tip #1: Implement Multiple Levels of Caching to Reduce Chances of a Cache Miss
Have you ever noticed that when you load a web page for the very first time, it takes a little bit longer than the second, third, etc. times that you visit that page? That’s an intelligent logic that goes behind the scenes in a web browser –– caching.
Caching makes it easier for an application to perform as it avoids or delays requests to the server every time a page has to load. However, caching in the case of complex apps is tricky. Here’s why it is advisable to implement multiple levels of caching in an application to make it scalable.
According to Jared Rerie,
“The argument that 'the server is caching, so why should the client?' is very common in my experience. Perhaps it’s because we’re taught as developers to avoid duplication (Don’t Repeat Yourself). One might argue that several teams implementing caching is a form of wasteful duplication of effort. While multiple layers of caching can introduce complexity to a system, it’s not wasteful and not even true duplication because client-side and server-side caching are potentially very different.”
Tip#2: Using Multiple Databases to Maintain Data Integrity in Complex Systems
It often becomes tedious to choose between a SQL and NoSQL database while developing an application that scales. Even worse, the marketing wave of both kinds of databases has made this decision even more difficult.
In the words of Frederic Faure, Architect at Ysance,
“I find the positioning of SQL and NoSQL (Not Only SQL) as opposites rather a shame: it’s true that the marketing wave of NoSQL has enabled the renewed promotion of a system that’s been around for quite a while, but which was only rarely considered in most cases, as after all, everything could be fitted into the « good old SQL model ». The reverse trend of wanting to make everything fit the NoSQL model is not very profitable either.”
In fact, a survey done by scalegrid.io suggested that 44.3% of businesses amalgamate two or three databases to scale their application. What’s more, SQL and NoSQL was the most popular multi-database combination employed by over 75.6% users.
Here’s why using multiple databases has a significant impact on improving website scalability.
Tip#3: Don’t Store State Unless You Have a Good Reason
Stateful vs Stateless is a common debate all over the web with developers divided over the benefits of both.
What all these debates have in common has little to no significance with respect to scalability. Stateless, which relates to not storing any state in your web applications, allows you to simplify the client/server communication model of your application. The major benefit of this is that the client can request anything from the server without storing the state of the server. Moreover, since there is no need to change the pool of sessions throughout the web servers, your application can scale out without any hassle.
On the other hand, there may be some use-case when it is a good idea to store state in your web application. Hughe Mckee, the developer advocate at Lightbend, explains the benefit of preserving state in a shopping cart application in his blog “How to build successful cloud-native solutions”. The article illustrates the scaling capability of stateful application with a shopping cart example.
Per Hughe,
“When it comes to cloud-native software systems, determining the best approach depends on the specific circumstances. This certainly applies when considering stateless versus stateful systems. In many cases, the stateless approach is an acceptable solution; however, there is a growing number of scenarios where using a stateful approach will be a better alternative. This is undoubtedly true for the ever-increasing demand for high-performance near real-time and stream-based systems. “
Tip#4: Go Asynchronous
It goes without saying that “Asynchronous programming is the proven way of increasing web scalability.”
But how true is this claim? Udi Dahan might have the answer.
In the words of Udi Dahan,
“Often, during my consulting engagements, I run into people who say, 'some things just can’t be made asynchronous' even after they agree about the inherent scalability that the asynchronous communication pattern brings. One often-cited example is user authentication — taking a username and password combo and authenticating it against some back-end store."
When you are using Asynchronous IO, you are handling thousands of requests at the same time without blocking any of them. Some single-threaded frameworks, such as Node.js, do this efficiently and more effectively.
Tip#5: Avoid Any Single Point of Failure
Failures are inevitable. Web applications need to be immune to any single point of failure. Whether it be your server, database, message queue, disk-drives –– all must be isolated and independent of functioning on their own to ensure that when they fail, your entire system doesn’t break down.
But, before you decide to isolate any failure or root-out any SPOF, ask yourself a certain set of questions: What if the piece of code you have written doesn’t work at all? What if you end up writing an old legacy code that is hard to maintain and scale at some point?
Sean Hull, Cofounder of Orbit, advises you to root out any single point of failure before preparing your system to scale.
In the words of Sean,
“If your data is on a single master database, that's a single point of failure. If your server is sitting on a single disk, that's a single point of failure. This is just technical vernacular for an Achilles heel. These single points of failure must be rooted out at all costs.”
Here's full-list of the experts who spoke from their experience: building a scalable web application