Stateless and stateful systems comparison

Introduction

Stateless and stateful systems are two distinct approaches in information technology which handle and manage data and transactions differently. This article explores the differences between these two concepts and provide examples of stateless and stateful technologies in both software development and infrastructure systems.

Stateless Systems

In a stateless system, the server or application does not store any information or state regarding past interactions with clients. Each request received is independent and self-contained, and the server does not rely on any previous context to process the current request. The server treats each request as if it were the first one from the client.

Characteristics of stateless systems include:

  1. No client-specific information or context is stored on the server.
  2. The server does not retain any session data or transaction history.
  3. Each request is processed in isolation, without any knowledge of previous requests.

Examples of stateless technologies in software development:

  1. RESTful APIs: Representational State Transfer (REST) APIs are typically stateless. Each request to an API carries all the necessary information for the server to process it, and the server responds accordingly. The server does not maintain any session or state between requests.
  2. HTTP: The Hypertext Transfer Protocol (HTTP) is stateless. Each HTTP request is independent and does not rely on past requests. The server processes each request based solely on the information contained in the request headers and body.

Examples of stateless technologies in software development with persistence cookies:

  1. .NET Web Applications: .NET web applications can be designed to be stateless, where the server does not retain session data. However, developers can use persistence cookies to store a token or identifier on the client-side, allowing the server to recognize and associate subsequent requests with a particular session or user.

Examples of stateless technologies in infrastructure appliances:

  1. Firewalls: Firewalls, such as packet-filtering firewalls, operate in a stateless manner. They analyze each network packet independently, evaluating its source, destination, and other attributes, without maintaining any session state.
  2. Network switches: Network switches generally function in a stateless manner by examining the packet headers and forwarding them based on their destination MAC addresses.

Stateful systems

In contrast to stateless systems, stateful systems maintain and manage session state or contextual information regarding client-server interactions. These systems store data about past interactions, allowing the server to remember and use the accumulated information to process subsequent requests.

Characteristics of stateful systems include:

  1. The server retains session-specific information or context between requests.
  2. Session state may include user-specific data, transaction history, or other relevant information.
  3. The server uses the session state to process requests and provide a more personalized experience to clients.

Examples of stateful technologies in software development:

  1. Session-Based Web Applications: Traditional web applications often utilize session state to store user-specific data. Each user is assigned a unique session ID, which is stored on the server, and subsequent requests from the same user are associated with the corresponding session, allowing the server to maintain context and provide a personalized experience.
  2. Shopping Cart Functionality: E-commerce applications commonly use session state to store and manage the contents of a user's shopping cart throughout the session.

Examples of stateful technologies in infrastructure appliances:

  1. Load Balancers: Load balancers can operate in a stateful manner by employing session affinity or sticky sessions. With session affinity, subsequent requests from a client are directed to the same backend server, ensuring session continuity and consistent handling of session-specific data.
  2. Application Delivery Controllers (ADCs): ADCs often provide session persistence capabilities, enabling them to maintain session state and direct subsequent requests from the same client to the appropriate backend server.

A general discussion comparing stateless vs stateful systems is available at: https://www.rosehosting.com/blog/stateful-and-stateless-horizontal-scaling-for-cloud-environments/.

Comparison

Stateless and stateful approaches each have their advantages and use cases. Stateless systems are highly scalable and promote easy horizontal scaling,as there is no need to manage session state across multiple servers. Stateful systems, on the other hand, allow for personalized experiences and the retention of session-specific data but may introduce complexities in managing session state and impose limitations on scalability. The choice between stateless and stateful approaches depends on the specific requirements of the application or infrastructure and the desired functionality and performance characteristics. The following image provides more details about the main points in which stateless differ from stateful.

Stateless and stateful systems comparison

Azure App Service ARR affinity cookie

Azure Web Apps is a stateless platform and, in an environment, where we are scaling the Website across multiple instances, the ARR Affinity cookie will be bound to a specific server. In case, the server is no longer in rotation, then all the requests corresponding to the ARR Affinity cookie will fail, meaning they wouldn't be able to access any in process information for that particular user on a different instance.

The following articles desribe in more detail the difference between stateful and stateless apps and the role of the ARR affinity cookie in Azure App Service scaling out capability: 

The relevant design architecture for resilient zone-redundant Web App in Azure App Service is described at: https://learn.microsoft.com/en-us/azure/architecture/web-apps/app-service/architectures/baseline-zone-redundant. The equivalent design for multi-region App Service is available at: https://learn.microsoft.com/en-us/azure/architecture/web-apps/app-service/architectures/multi-region