Stateless service
A service where any instance can handle the next request because no user's required state lives only in one server's memory.
See it
What it is
A stateless service keeps no per-user memory in one server process that a later request needs. Each request carries enough identity and context to be handled by any healthy instance, while durable state lives in a database, object store, or shared cache. The service still uses state; it just does not pin correctness to one process.
Reach for this shape when instances must scale horizontally, restart freely, or sit behind a load balancer without sticky sessions. Kubernetes Deployments fit it well because a replacement Pod can take traffic without inheriting another Pod's memory. This is what the cattle-not-pets phrase from cloud operations describes: instances are numbered and replaceable rather than named and nursed.
Gotcha: moving every value into Redis does not automatically make a good stateless design. Shared state adds latency and failure modes, signed tokens can go stale, and WebSocket connections still live on particular processes while connected. Keep local caches disposable, make retries safe, and design explicit homes and lifetimes for state.
Ask AI for it
Refactor this API into a stateless Kubernetes Deployment with at least three replicas behind a Service. Move session data to Redis with an explicit TTL, put uploaded files in Amazon S3, remove sticky-session requirements, and make mutating endpoints idempotent with an Idempotency-Key record in PostgreSQL. Add readiness and liveness probes, graceful SIGTERM handling, and an integration test that starts a request on one Pod and sends the next request to another.