Scalable Web by Stateless Development

Scalability is the ability to grow your web service to many users, it requires a special attention especially since recently there is a popular misconception that “if you host in the cloud, your application will be scalable”.  Well unfortunately this is wrong, “the cloud” hasn’t got any magical solutions, hosting in the cloud could actually make your web application slower and less scalable, if not developed in the right way. The good news is that sclability is not so hard to achieve, if you understand the basic concept of Stateless Web Programming:

Don't store any user state on the web server side

It means that you need to say goodbye to several “lazy programming” practices, in particular, you should stop using SESSION variables to store user state variables like user id, user name, permissions level, etc. I will explain below the details and how to implement stateless web development; this is fairly easy.

Why Stateless Is Scalable?

“Stateless” is scalable since the best way (so far) to increase service volumes is to distribute the databases instead of trying to distribute the web service. At a high level, most web applications have two main components: a web server and a database server. The web server (usually Apache, IIS, Nginx, etc.) serves the HTML content, and the databases store long-term data like user information and content.

The HTTP protocol, by design, is stateless—each HTTP packet requested by the browser is independent of the other packets (that’s why in some cases, on the same web page, different elements are served by different routes). However, web servers can identify a browser session even if the user is flicking between different web pages; actually, the browser session stays alive, as defined in the server’s configuration variables, for a certain time even if the user completely leaves the site.

So, if the user session could be identified by a web server, the next level is to define “session variables” which are stored on the web server. Developers use those web server session variables to store some “rapid access” information. For example, if a user logs in to the system, the server session variables can store the fact that the user has permission to access a specific site functionality.

Now, imagine that we try to scale this web app and host it on several servers… and that a user named Suzy is starting her session with SERVER NUMBER 1 and then flicks to another page which is now served by SERVER NUMBER 5. Obviously, SERVER NUMBER 1 and SERVER NUMBER 5 have different session variables, which means that SERVER NUMBER 5 won’t know that Suzy has permission to view that specific page. If the application was designed without using the session variables, it would be scalable.

How to Develop a Stateless App?

The solution is not to store any states on the web server side, but to use the client side or the databases (or both) to store it. This can be done in many ways. Considering the above example, the developers could have:

1. Once Suzy logs in, store a cookie in Suzy’s browser. The cookie will contain Suzy’s User ID, and let’s call this cookie “cookie_user_id.”
2. Store all of Suzy’s user permissions, like which pages she is allowed to access, on the database side.
3. For each hit to the webserver (any click/ajax request/form request), send the value of cookie_user_id with the request.
4. For each request served by the web server, read the permissions table by using the value of cookie_user_id to query the right table’s row.

Databases, unlike webservers, are easily scalable (I will devote a new blog to that subject in the future). It means that if you host a stateless application and scale it by building several web servers and several database servers, the stateless conditions will guarantee that your web app will continue to work properly.

All the best 🙂

Eran

Inspired by: https://www.cleverquantum.com and Quantum Computing Blog