Stateless
Stateless architecture means each request is independent and self-contained, with no server-side session data stored between requests.
In software architecture, stateless refers to a design in which each request from a client to a server is treated as an independent transaction. The server does not retain any information about previous requests from the same client. Every request must carry all the data needed for the server to process it -- including authentication credentials, context, and parameters.
Stateless vs. stateful
In a stateful system, the server remembers information about the client between requests. A classic example is a web application that stores a session object on the server after login, so subsequent requests can reference that session by ID. The server must keep this session data in memory or a shared store.
In a stateless system, there is no server-side session. Each request is self-contained. Authentication is typically handled by including a token (such as a JWT) with every request, which the server validates independently without looking up stored session data.
Server memory
Stores session data
No session data stored
Scalability
Harder -- sessions must be shared or sticky
Easier -- any instance can handle any request
Failover
Session loss if a server goes down
No session to lose
Request size
Smaller (references session)
Larger (carries all context)
Why stateless matters for APIs
Statelessness is one of the core constraints of REST and a fundamental property of well-designed APIs. Its practical benefits include:
Horizontal scaling: Because any server instance can handle any request, you can add or remove instances freely behind a load balancer without worrying about session affinity.
Fault tolerance: If a server instance fails, in-flight requests fail but no persistent state is lost. Clients can retry against any other instance.
Caching: Stateless responses are easier to cache because the response depends only on the request, not on hidden server-side state.
Simplicity: Removing server-side session management eliminates an entire category of bugs related to session expiration, synchronization, and storage.
Stateless architecture in practice
Making a system stateless does not mean there is no state at all -- it means state is managed outside the request-handling layer:
Authentication tokens: JWTs carry the user's identity and permissions in the request itself, eliminating the need for server-side session lookups.
Databases: Persistent application state lives in a database that all server instances can access.
Caches: Frequently accessed data is stored in external caches like Redis, not in per-server memory.
Client-side state: Clients maintain their own state (e.g., shopping cart contents) and send it with each relevant request.
Stateless design and API gateways
API gateways are themselves designed to be stateless. Each request is processed independently: the gateway authenticates, routes, and transforms the request without reference to any previous request. This is what makes gateways horizontally scalable and suitable for edge deployment.
Serverless API Gateway runs on Cloudflare Workers, which is inherently stateless. Each request is handled independently by whatever edge location is closest to the user. There is no shared memory between invocations. Authentication is handled via JWT validation on each request, fitting the stateless model. This architecture allows the gateway to scale to arbitrary traffic levels without session management or sticky routing.
Related documentation
Authorizer Configuration - Stateless JWT authentication on every request
Configuration Overview - Declarative, stateless gateway configuration
Getting Started - Deploy a stateless API gateway at the edge
Last updated