Stateless Service

A stateless service is one whose instances hold nothing between requests that another instance would need. The state still exists — in a database, a cache, a queue, a token the client carries — it just does not live inside the process handling the request. Any instance can serve any request, and losing one loses no information.

That property is what makes several things possible at once: scaling out by adding instances, replacing an instance during deployment, and recovering from a crash without a special procedure. They are the same property viewed from three angles.

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.

Serverless platforms make the line unusually visible because they document both halves. After an invocation, the execution environment “is frozen” and may be reused, so objects declared outside the handler “remain initialized” and the temporary directory — “between 512 MB and 10,240 MB” — persists as “a transient cache that can be used for multiple invocations.” A database connection or a loaded model kept there is a legitimate optimization. Descriptions here follow the AWS Lambda documentation, checked in September 2026.

The same page states why it cannot be more than a cache: “Lambda terminates execution environments every few hours to allow for runtime updates and maintenance—even for functions that are invoked continuously. You should not assume that the execution environment will persist indefinitely.” Anything that must survive belongs elsewhere, and that rule applies equally to a container, a virtual machine behind a load balancer, or a pod being rescheduled.

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.”
• Counters and accumulators in memory. A rate limit or running total held in the process is wrong as soon as there are two instances, and silently so — each instance counts its own share.
• 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.

Each of those has the same signature: it works with one instance and fails intermittently with several. That is why they survive testing and appear after a scaling event.

Statelessness needs idempotency to be useful

Being stateless makes an instance replaceable. It does not make a retry safe. If a request is interrupted after charging a card and the client retries against another instance, statelessness guarantees the second instance can serve it — and guarantees nothing about the double charge.

So the two properties travel together: idempotency is what makes the repetition harmless, usually through a request key the service records. A stateless service without it scales cleanly and duplicates work under exactly the conditions that make scaling necessary.

When it cannot be stateless

Some workloads genuinely need local state: a stream processor maintaining aggregates, an in-memory index, a long-running computation with intermediate results. The answer is not to pretend otherwise but to make the state recoverable — checkpointed to durable storage, or rebuildable from a log — so that losing an instance costs time rather than correctness.

Which changes the operational profile rather than removing the constraint. A stateful instance can still be replaced; it just takes as long as restoring its state, and that duration becomes a number worth knowing before an incident rather than during one.

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.