NOTE
1.12 Stateful and Stateless Services
How state placement changes routing, scalability, recovery, and storage dependencies in distributed services.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What Is Service State?
State is information that must survive or influence more than one operation: session data, in-memory working sets, ownership, cached metadata, or durable business data.
- A stateful service instance owns state that affects where later requests can be processed.
- A stateless service instance keeps no request-critical local state between calls, so any healthy instance can usually handle the next request when shared state is available elsewhere.
2. Stateful vs. Stateless
| Stateful | Stateless | |
|---|---|---|
| Routing | Often needs affinity or ownership routing | Usually any healthy instance |
| Scaling | Requires state movement, sharding, or rebalancing | Instances can usually be added/removed easily |
| Local access | Can be very fast | Often depends on remote/shared storage |
| Recovery | Must restore or reconstruct owned state | Replace instance and reconnect to shared dependencies |
Neither model is universally better. Databases, stream processors, and caches are naturally stateful; many API services deliberately externalize durable state to simplify horizontal scaling.