REL05-BP06 Make services stateless where possible - AWS Well-Architected Framework (2023-04-10)

REL05-BP06 Make services stateless where possible

Services should either not require state, or should offload state such that between different client requests, there is no dependence on locally stored data on disk and in memory. This allows servers to be replaced at will without causing an availability impact. Amazon ElastiCache or Amazon DynamoDB are good destinations for offloaded state.

In this stateless web application, session state is offloaded to Amazon ElastiCache.

Figure 7: In this stateless web application, session state is offloaded to Amazon ElastiCache.

When users or services interact with an application, they often perform a series of interactions that form a session. A session is unique data for users that persists between requests while they use the application. A stateless application is an application that does not need knowledge of previous interactions and does not store session information.

Once designed to be stateless, you can then use serverless compute services, such as AWS Lambda or AWS Fargate.

In addition to server replacement, another benefit of stateless applications is that they can scale horizontally because any of the available compute resources (such as EC2 instances and AWS Lambda functions) can service any request.

Level of risk exposed if this best practice is not established: Medium

Implementation guidance

  • Make your applications stateless. Stateless applications allow horizontal scaling and are tolerant to the failure of an individual node.

    • Remove state that could actually be stored in request parameters.

    • After examining whether the state is required, move any state tracking to a resilient multi-zone cache or data store like Amazon ElastiCache, Amazon RDS, Amazon DynamoDB, or a third-party distributed data solution. Store a state that could not be moved to resilient data stores.

      • Some data (like cookies) can be passed in headers or query parameters.

      • Refactor to remove state that can be quickly passed in requests.

      • Some data may not actually be needed per request and can be retrieved on demand.

      • Remove data that can be asynchronously retrieved.

      • Decide on a data store that meets the requirements for a required state.

      • Consider a NoSQL database for non-relational data.

Resources

Related documents: