LinuxLVIII · Clustered Service ArchitectureStateless
Stateless services - the simplest cluster architecture
What you'll learn
- Define stateless service
- List the properties that make a service stateless
- Recognise common stateless patterns
- Design stateless services for the cluster
Prerequisites
Verified against Ubuntu 24.04 LTS · Debian 12 (Bookworm) · RHEL 9.x · Rocky Linux 9.x · AlmaLinux 9.x · Linux kernel 6.1 LTS / 6.6 LTS · systemd 255+ · OpenSSH 8.7p1 (RHEL 9) / 9.6p1 (Ubuntu 24.04) · nftables 1.0.x · chrony 4.x · Pacemaker 2.1.x · Corosync 3.1.x · 2026-08-09
A stateless service holds no session state in memory. Every request is independent. This is the simplest cluster architecture and the foundation of scalable web services.
What is stateless
A stateless service:
- Holds no client session in memory.
- Stores no state in local files.
- Each request is independent; processing one does not require state from a previous one.
Examples:
- nginx (serves static files; no per-request state).
- Stateless API (no session in memory; state in DB).
- CDN (serves cached content; origin is the source of truth).
Why stateless is the foundation
- Easiest to scale: add instances, distribute load.
- Easiest to fail over: any instance can handle any request.
- Easiest to test: no state to set up; just request the endpoint.
- Easiest to operate: no stateful logic to debug.
Stateless is the “easy mode” of cluster architecture. The discipline is to keep it stateless where possible.
Properties of a stateless service
- No local state: no sessions, no caches (or only read-only caches).
- All persistent state in a database or external store.
- Any instance can handle any request.
- No sticky sessions required (though they may still be used).
When stateless is not possible
Some applications have stateful logic by nature:
- Database (state is the data).
- Long-running job queue (state is the queue).
- WebSocket server (state is the open connection).
- Game server (state is the game world).
For these, stateless is not possible. The state lives somewhere (DB, queue, in-memory). The cluster must manage that state.
Design patterns
Stateless API
- All state in the database.
- Any instance can handle any request.
- Session token in a cookie or header (stateless JWT).
- The DB is the single source of truth.
CDN
- Static content cached at edge.
- Origin is the source of truth.
- Cache invalidation on origin update.
Worker pool
- Jobs in a queue (SQS, Kafka, RabbitMQ).
- Workers pull jobs; no shared state.
- Multiple workers, no coordination needed.
Knowledge check
Knowledge check · 3 questions
Q1. What is a stateless service?
Q2. All services can be stateless.
Q3. Which of the following are properties of a stateless service? Select all that apply.
Passing score: 75%. Answers are checked in this browser.