# Stateless

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.

| Aspect        | Stateful                                    | Stateless                                     |
| ------------- | ------------------------------------------- | --------------------------------------------- |
| 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](/configuration/authorizer.md) - Stateless JWT authentication on every request
* [Configuration Overview](/configuration/overview.md) - Declarative, stateless gateway configuration
* [Getting Started](/getting-started/introduction.md) - Deploy a stateless API gateway at the edge


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.serverlessapigateway.com/glossary/s/stateless.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.