Scalability Choices in Software Architecture, III of III

Stateful Server vs Stateless Server

Typically, a stateful server will keep session data in memory. Tremendous performance gains can be achieved when session data is in memory and database access is avoided.

The drawback of stateful server is that, a client gets associated to a particular server. If the server is to be brought down for upgrade or maintenance purpose, session data is lost. Of course, session data can be replicated to another server, or passivated into a persistent store to be re-incarnated into other servers, but this complicates overall implementation.

Still in certain category of applications, performance gains of stateful servers are too valuable to ignore. Consider a complex process like product configuration. With 100s of items with complex dependencies and constraints, a configuration state is better stored in the session in memory rather than the database. Otherwise performance will be horrendous.

If situation permits though, stateless server architecture is preferred because of its simplicity.

Situation one: the states are not that complex and can be easily and cheaply reconstructed from persistent store. To further improve performance, the states can be stored in a shared cache, so the servers are stateless, but still database access is avoided.

Situation two: if using RIA, the state can be moved to the client, and the server can easily be stateless, even for the most complex states. In fact this is the direction the world is going. This paradigm is further popularized by native apps on smartphones and tablets, so this is not just browser-based.

Conclusion

Ultimately the situation will dictate the choice, but in most cases, vertically partitioned, horizontally scaled, stateless servers supporting RIA clients would be the architectural choice for scalability.