Stateless Service

A stateless service does not require later requests to recover a particular instance’s previous local state to produce correct results. Shared databases, queues, caches, or client-carried tokens can hold the needed state. This makes instances replaceable, but losing an instance can still lose in-flight input, progress, or a response. Accepted work needs a separate durability protocol, such as committing or durably enqueueing it before acknowledgment and handling retries safely.

This property supports adding instances, replacing them during deployment, and recovering after a crash. Successful replacement still depends on available dependencies, compatible configuration, and a protocol for interrupted work.

Cache in the instance, keep truth outside it

Stateless does not forbid using local memory or disk. It forbids depending on them. The distinction is between a copy you can rebuild and information that exists nowhere else.

The standard AWS Lambda lifecycle permits reuse of an execution environment after an invocation. Initialized objects and temporary files may be available to later invocations in that same environment. A cached model or reusable database connection can therefore save work, subject to validation and connection health checks.

Lambda can retire or replace that environment, including for maintenance. Do not use its local cache as the only copy of required state. Apply the same failure analysis to other execution models: if a container or VM disappears, identify which state survives in independent storage and how a replacement obtains it.

Four things that quietly break it

• Session state in the instance. The classic case. It works until traffic grows, and then it forces requests from one user back to one instance — which turns a capacity problem into a routing problem and makes deployment disruptive. Put the session in a shared store or in a signed token the client carries.
• Files written locally and read later. An upload saved to local disk and processed by a subsequent request assumes the same instance handles both. Worse, a reused environment can expose leftovers: after an invocation failure the platform resets the environment, and that reset “does not clear the /tmp directory content before the next init phase.”
• Global counters kept only in memory. An instance-local counter cannot by itself enforce a service-wide rate limit or total across several instances. Coordinate authoritative shared values according to the required consistency. Counters intentionally used for per-instance protection or local metrics can correctly remain local.
• Background work that outlives the response. Fire-and-forget tasks assume the process stays alive. The documentation warns that incomplete background processes or callbacks “resume if Lambda reuses the execution environment,” which means they run at an unpredictable time or not at all. Work that must happen belongs on a queue.

These designs can hide dependencies on instance lifetime or request routing. Test instance loss and replacement as well as scale-out; a process can fail even when it is the only instance.

Retryable mutations need effect protection

Being stateless makes instances easier to replace. It does not make a retry safe. If a request is interrupted after charging a card, a retry sent to another instance must determine whether the original effect committed.

For retryable mutations, idempotency prevents duplicate effects through a protocol such as durable request-key tracking coordinated with the state change. Statelessness and retry safety solve different problems. A read-only request need not use the same effect-deduplication mechanism, and a key alone is insufficient if its record can diverge from the side effect.

When it cannot be stateless

Some workloads maintain local state: stream aggregates, in-memory indexes, or intermediate computation results. Make that state recoverable from a durable checkpoint or retained input. Recovery also needs compatible code and state formats, a known input position, and a sink protocol that reconciles effects already committed before failure.

A stateful instance can be replaced within those recovery conditions. Measure restoration and catch-up time, verify that input retention covers the recovery window, and test the output boundary. A checkpoint alone does not guarantee either fast recovery or correct replay.

How statelessness shapes the choice between virtual machines, containers, and serverless — and what the execution model demands in each case — is worked through in You Rented the Server, Not the Outcome.

References

• AWS Lambda Developer Guide, Understanding the Lambda execution environment lifecycle
• Microsoft Learn, Shared responsibility in the cloud