Statelessness and Scalability
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Statelessness means an API instance does not keep hidden client-session context that a later request must recover. Each request supplies the resource identifier, credentials, any representation, and other context needed for that interaction. Orders, users, permissions, idempotency records, and logs can still remain on the server. The constraint removes per-client conversation memory from the request-handling instance, not business data from the system.
A load balancer can send GET /orders/42 to Instance A and the next complete request to Instance B. Since neither instance needs a private currentOrder or checkout-step variable, the tier does not need sticky sessions just to preserve conversation context. New instances can join, old ones can leave, and a failed instance can be replaced without losing required client-session memory.
Durable progress becomes resource state in shared storage. For example, POST /exports can create an export and return Location: /exports/E7; any instance can later handle GET /exports/E7 by loading that resource. This scales the API tier, but it does not make the whole system limitless. A database, authorization service, or shared cache can still become a bottleneck or failure point and must be designed separately.
Self-contained requests may repeat credentials and context, perform repeated lookups, and use more bandwidth. They do not require JWT; an opaque token can work if the request remains independently understandable. If an instance dies during a request, that request may still fail, and retry safety depends on idempotency and business rules. Statelessness is especially important for horizontal scaling, but cacheability, layering, and the uniform interface also contribute to a scalable REST system.
Statelessness and Scalability
Direct Answer
Statelessness is especially valuable for horizontal scaling because any capable server can understand a request without retrieving conversational session context from the previous server. It improves visibility, failover, and routing, but it is not objectively the only important REST constraint and it does not require JWT; each request only needs sufficient context for that interaction.
Deep Dive & Architecture
Fielding distinguishes resource state from application state. The origin stores resources such as an order and its current status. The client drives application progress by choosing links and submitting representations. The server does not remember a hidden conversational step that a later request requires but does not contain.
Removing per-instance session context changes failure behavior. If an instance disappears after a response, another instance can process the next complete request. Shared databases and authorization services can still be consulted; the key is that understanding does not depend on undocumented conversation memory attached to one server process.
Authentication technology does not determine RESTfulness. A self-contained signed token can reduce lookups but creates revocation and freshness trade-offs. An opaque token can be resolved centrally and still support independently understandable requests. Neither choice excuses an API from authorization checks or credential protection.
Long-running work can remain stateless at the interaction layer by becoming a resource. A client posts an export request, receives /exports/E7, and later reads its status. The workflow state is explicit, addressable resource state rather than an invisible session variable. This makes retries, monitoring, and recovery clearer as well as scalable.
Code Example
POST /exports HTTP/1.1
Authorization: Bearer <credential>
Content-Type: application/json
{"report":"monthly-sales"}
HTTP/1.1 202 Accepted
Location: /exports/E7
GET /exports/E7 HTTP/1.1
Authorization: Bearer <credential>
The export's progress is server-side resource state. Either API instance can understand the later GET from its URI and credential without remembering which instance accepted the POST.
Check your understanding
Answer these without looking back at the article.
- What is the difference between resource state and client session context?
- Does REST statelessness require JWT authentication?
- How can a long-running workflow remain stateless at the request level?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.