Coding in the Cloud – Rule 3 – Use a “Stateless” design whenever possible

Coding in the Cloud

By Adrian Otto

This continues my series on Rules for Coding in the Cloud, rules I’ve developed after watching applications encounter problems at scale when deployed on Cloud Sites.

The use of Sessions

The Web was originally designed to be stateless, that is, not to rely on information about users being stored between interactions. Sessions are a way to save the state of the application for the user between requests (shopping carts being the classic example of this). Programmers, feeling that they need to save information about particular users between interactions, find all sorts of ways to use sessions that are not really appropriate.  As a result, the concept of sessions gets abused and the scalability of the applications suffers due to requiring sessions. If you can design your application not to use sessions at all and be completely stateless, it can be scaled horizontally much more easily and the application will run much better under high load than if you try to keep track of which user needs to be reconnected with which session settings.

The error that we often see is that the application programmer makes a dependency on sessions central to the design of the software, and later when it becomes identified as a scalability bottleneck, it cannot be removed from the application because it was designed in at such a low level.

The reason why sessions are so evil is that most developers store the session information in the database. To get the information you need out of the session, you need to query the database and read the information. And because sessions change so often, such applications require lots and lots of writing to the database to keep the state of the session. You can end up with a read/write ratio of about 50/50 because of sessions, which kills scalability.

Working with REST

One way to make sure you don’t rely on sessions is to use Representational State Transfer (REST) architectures, which are by definition stateless.

If your application can work with REST, sessions are a non-issue.  If you have a REST architecture, you can put Ajax on top of REST and have a very useful application. Ajax can maintain information on the client side, which is fine for many applications. Going back to the shopping cart example, you could implement a shopping cart using Ajax. You could work around a lot of the storage that would be required by storing it in the JavaScript app that’s running on the client and give it to the server at the end of the interaction.

Some types of information are stateful by nature,  such as something that requires an open network connection to monitor progress of a remote operation that does not have stateless features. In such cases, using a stateless design may not be practical, or even possible. When you have more clients than servers it makes sense to do as much work on the clients as you reasonably can.  If your application must save state, save it on the client rather than on  the server. Consider using a browser cookie, or some Ajax. This will greatly improve your scalability.  Furthermore, you pay for the server side resources you consume, but client side resources are free!

Bottom line: Stateless apps are ideal. Server-side database writes are your enemy. If you must save state, save it on the client. Use cookies and Ajax where appropriate. If you follow this rule, you will multiply your scalability.

Before leaving in 2016, Angela ran integrated marketing campaigns for Rackspace. She started in 2003 and did everything from Linux support, account management, sales, product marketing and marketing. She left Rackspace in 2005 to work for PEER 1 Hosting but returned in 2009 because she was interested in the cloud computing movement. Angela is a strong believer in the power of storytelling.


  1. As of 2.x, Rails addresses this problem by defaulting to cookie-based sessions. This of course introduce its own overhead, and has security implications (don’t store sensitive information in cookies), but if used wisely is a perfectly acceptable method of maintaining state between requests.

    I’ve always viewed pure REST as a sort of unattainable utopia, and I defy anyone to show me a purely RESTful application. In most cases, the difficulty in developing such an app far outweighs any benefit in having done so. In *most* cases. I’ve been asked more than once why I didn’t make the API RESTful, and I always respond with a question: “Why should I have?” No one’s ever had an answer.

    One issue I never see addressed satisfactorily with regards to REST is authentication. Without cookie data (which is essentially a cookie-based session whether you call it that or not – and as soon as you introduce it you’ve introduced state, and are by definition not RESTful), you’re left with HTTP basic auth, which really should be put out to pasture right next to IE6.

  2. In PHP, sessions by default uses a file storage system and cookie for storing the filename (though you can change this settings to use a db instead). Do you think the file storage method has big effect on scalability? What is a stateless approach to user authentication and their state maintenance?

    • Of course local storage will effect scalability, as they are local. It’s ok if you only have one server, but when you add a second one and need session between servers, you need to implement some distributed solution, db or memcached for example.

  3. I have gone a different way with respects to sessions and DB interaction, I use a hash I generate and store it in a table named sessions, then pass it in the header to my frontend thats written in JS. Store that var in local storage and use it to auth every function, with a filter I built that looks for it and finds it in the DB either failing or passing auth…. To prevent token hijacking I use a wildcard ssl cert… 🙂

    Hope this helps someone out there! 🙂


Please enter your comment!
Please enter your name here