C2
Stateless Requests, Stateful Applications
See how a stateless model or protocol can participate in a stateful product without hidden session assumptions.
- 01Distinguish stateless processing from a memoryless product
- 02Locate state in the application instead of the model or transport
- 03Pass explicit identifiers when work spans requests
Stateless does not mean forgetful
mental modelA stateless request contains everything needed to process that request. A stateful application may still load a conversation, checkpoint, or user preference and include it explicitly.
Stateless requests begin from supplied input. Stateful execution writes a checkpoint and can reload it after an interruption.
Text description
Stateless requests begin from supplied input. Stateful execution writes a checkpoint and can reload it after an interruption.
Example: a report job
The user starts a report, closes the laptop, and returns tomorrow.
- A stateless endpoint receives
taskIdand the next action. - A durable task record stores progress and ownership.
- A checkpoint stores the workflow state needed to resume.
The system is stateful, but each request still carries an explicit task identifier.
Common MisconceptionA long-lived connection is the same as a session.
CorrectionA transport channel can carry unrelated requests. Session meaning must be explicit in data and identifiers.
Deep dive: Horizontal scaling
Stateless request handling lets any healthy replica process the next call. Durable state belongs in shared storage, not one server’s memory. This improves failover and makes retries easier to reason about.
References & deeper reading (2)
- MCP Base Protocol and StatelessnessModel Context Protocol
- LangGraph PersistenceLangChain Docs
Retrieval Practice
Check one idea at a time
What makes an application stateful?