What is Stateless?
A stateless service does not keep server-side session state between requests. Each request must carry enough information for the service to process and authorize it. Stateless design can simplify scaling, but it is not inherently more secure. Revocation, replay protection, logout, rate limits, and policy changes can require shared state or short credential lifetimes. A stateless firewall cannot correlate packets into connection state.
Why it matters
A stateless request can be handled by any service replica, which can simplify scaling and recovery. Teams must still identify the state needed for current authorization, abuse controls, and credential revocation.
How it works
- Each request carries the data or credential that the receiving service needs for processing.
- A service replica validates the request without relying on a session stored only in that replica.
- The service returns a result, while any required shared controls use external state or short credential lifetimes.
Example
Any API replica can validate a short-lived signed JWT and process the request without local session affinity.
Pomerium boundary
Pomerium can send a short-lived signed JWT assertion to an upstream service for each authorized HTTP request.
Limits and non-claims
- Stateless design does not make a service secure or make its authorization rules correct.
- A self-contained credential can be hard to revoke before expiry without a shared check.
- Replay controls, rate limits, logout, and connection tracking can require shared state.
Evaluation checklist
- Which state travels with each request, and which trusted party signs or validates it?
- How do expiry, replay prevention, revocation, policy change, and key rotation affect accepted state?
- Which caches, identity providers, keys, logs, or recovery systems remain hidden stateful dependencies?
