Junior Level

Stateless means the server does not store client session information between requests. Each request is processed as if it were the first.

This means the server doesn’t need to remember who you were 5 seconds ago. Each request is like first contact with a stranger: the client must present all necessary data (token, parameters).

Core Principles:

• Each request is independent: The server doesn’t remember what the client did before
• Client holds state: All session information (token, parameters) is sent with each request
• Server stores only data: Data in the DB (products, users) is not session state — this is allowed

Example:

// Each request contains an authorization token
// The token is sent every time because the server doesn't remember you between
// requests — that's what Stateless means.
GET /users/1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

GET /users/1/orders
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Advantages of Stateless:

• Since the server doesn’t need to store sessions, any request can go to any server. No sticky sessions needed, no session synchronization between nodes.
• Any server can handle any request
• Easier deployment and maintenance

---

Middle Level

Where is state stored?

1. On the server (Resource State): Data in the database — this is allowed
2. On the client (Session State): Session information (token, filters) — this is required for Stateless

TLS and Session Resumption

State exists at the TCP/TLS level:

• TLS Session Tickets: The client stores an encrypted session ticket
• TLS Session ID: Allows skipping full Handshake on every request
• REST remains “Stateless” at the application level, even though infrastructure may be “Stateful”

Cookie vs Header

• Cookie is sent automatically — convenient for browsers
• Authorization: Bearer is more flexible for mobile apps and helps avoid CSRF attacks

Token Bloat

If you store too much data in a JWT (roles, permissions, full name), the header size grows:

• Solution: Store only sub (ID) and critical scopes in the token
• Fetch the rest from a fast cache when needed

Diagnostics

• Sticky Session Check: In Kubernetes/Nginx, verify that sticky sessions aren’t enabled
• Distributed Tracing: Correlation ID (X-B3-TraceId) is the only way to link requests from the same client

---

Senior Level

JWT Revocation Problem

JWT is a Stateless tool. But if you need to instantly log out a user (e.g., token theft), you must check a “blacklist” of tokens in Redis.

Paradox: As soon as you add token verification in a DB/Redis on every request, your application effectively becomes Stateful, because it depends on a shared external store of session states.

Impact on Highload and Scaling

Zero-Downtime Deployment

With Stateless architecture, you can kill any server instance at any time. The client simply switches to another instance.

Data Locality and Anycast IP

Stateless allows using Anycast IP. A request from Tokyo hits a server in Tokyo, from London — in London. With sessions, you’d have to synchronize them across continents.

Edge Cases

Race Conditions in Client Session

If a client sends two parallel Stateless requests updating the same resource:

• Solution: Optimistic Locking (If-Match + ETag)

Server-Side Rendering (SSR)

With SSR, the server often needs state for initial rendering. This creates hybrid models: first load is Stateful, subsequent API calls — Stateless.

Performance

• Race conditions require Optimistic Locking via If-Match + ETag
• SSR often involves hybrid models (first load Stateful, API — Stateless)

---

Interview Cheat Sheet

Must know:

• Stateless means the server does not store client session state between requests
• Each request must contain all necessary information (token, parameters)
• Data in DB (resources) is not session state — storing it is allowed
• Stateless allows horizontal server scaling without sticky sessions
• JWT is a Stateless tool, but adding Redis verification makes the system Stateful
• TLS Session Tickets exist at the infrastructure level, but the application remains Stateless

Frequent follow-up questions:

• What’s the difference between Session State and Resource State? — Session State (client session) is stored on the client, Resource State (DB data) — on the server, which is allowed
• Why does JWT revocation create a problem? — Verifying the token in DB/Redis on every request makes the application Stateful
• How to link requests without sessions? — Through Correlation ID (X-B3-TraceId) for distributed tracing
• What is Token Bloat? — When a JWT contains too much data, increasing header size

Red flags (DO NOT say):

• “Stateless means the server stores nothing at all” — the server stores data (DB), just not sessions
• “Cookie and Bearer tokens are the same” — Cookies are sent automatically, Bearer — manually; Bearer protects against CSRF
• “Stateless can’t be scaled” — Stateless actually simplifies horizontal scaling

Related topics:

• [[What is REST]]
• [[Which HTTP methods are idempotent]]
• [[What is the difference between 401 and 403]]
• [[How to organize REST API versioning]]