Stateless vs Stateful
Learned in SE464.
An important distinction when designing scalable services.
Stateless
A stateless thread/process/service remembers nothing from past requests.
- Behavior is determined entirely by
<input request, request-handling code>. - Different copies of the service run the same code, so they give the exact same response for a given request.
- Has no local state.
Stateless services scale horizontally easily; any worker can handle any request.
Stateful
A stateful thread (or service) changes over time as a side effect of handling requests.
- Persistent, global variables are modified by the request-processing code.
- Example: SMTP maintains a state for the duration of a single mail transaction (a session between client and server). The protocol needs state to track the HELO/EHLO → MAIL FROM → RCPT TO → DATA sequence.
Stateful services are harder to scale:
- Users must connect to the exact same server to continue their session. How do you route them?
- If a server fails, 1/n sessions are lost or interrupted.
Pattern
The first idea is often to make the service stateful. But it’s usually better to make the service stateless and push state to a shared backend (DB, cache).