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

Filed in by Angela Bartels | July 17, 2009 9:28 am

Coding in the Cloud

By Adrian Otto

This continues my series on Rules for Coding in the Clou[1]d[2], 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)[3] 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 [4]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.

Endnotes:
  1. Rules for Coding in the Clou: http://www.rackspacecloud.com/blog/2009/07/coding-in-the-cloud-rule-2-dont-write-to-the-database-in-real-time/
  2. d: http://www.rackspacecloud.com/blog/2009/06/coding-in-the-cloud-%E2%80%93-rule-1-cache-is-your-friend/
  3. Representational State Transfer (REST): http://en.wikipedia.org/wiki/Representational_State_Transfer
  4. Ajax : http://en.wikipedia.org/wiki/Ajax_(programming)

Source URL: http://www.rackspace.com/blog/coding-in-the-cloud-rule-3-use-a-stateless-design-whenever-possible/