Stateful versus stateless architecture

01Stateless means independent request handling

A shopper sends two requests: first add a book to a cart, then display the cart. Ask where the information from the first request lives.

• Stateful worker: worker A keeps the cart in its own memory, and the later request depends on reaching A or recovering that memory elsewhere.
• Stateless request worker: each request identifies the user and cart. Either worker A or B can load the saved cart; neither needs history kept only in its own process from an earlier request.

“Stateless” does not mean the application has no data. Accounts, carts, orders and permissions still exist in persistent stores. It describes how a particular request-handling layer depends on local history.

Different information has different loss consequences. A product-cache copy can be rebuilt from the database. Losing the only saved purchase record loses a business fact. A live network connection is temporary again: its failure requires reconnection even when all messages remain safely stored.

02Find the recovery boundary

Plan recovery by following each kind of information:

For ordinary cart requests:

1. The client identifies the cart and authenticates. A user token names the caller; it does not recreate missing cart contents.
2. Any eligible worker loads the saved cart. Shared storage adds latency and a failure dependency, but makes history recoverable outside one process.
3. The worker checks concurrent changes before writing. Sharing a location does not prevent two workers overwriting each other's edits.

Some operations benefit from one stateful worker. A game-room server can apply moves locally in order. Save its accepted moves or checkpoints so a replacement can reload them. Give each replacement a new writer-permission number; the game store must check that number together with saving a move, and reject the old worker’s number. A worker reports acceptance only after that guarded save succeeds.

Sticky routing only sends the client back to the same worker. It neither saves a checkpoint nor copies memory to a replacement.

03Worked example: cart and chat connection

Cart 42 contains one item at version 7. Follow two devices:

1. The phone asks worker A to add a book. A reads version 7.
2. A browser tab asks worker B to remove the original item. B also reads version 7.
3. A saves its change as version 8. If B blindly replaces the whole cart using its old copy, B can erase the new book.
4. B submits a conditional update: replace the cart only if its saved version is still 7. The store compares and changes the record in one indivisible operation. Because it now holds 8, B's update conflicts instead of silently overwriting it.
5. B reloads the cart. After reloading, it can apply the tab’s explicit instruction to remove the original item while preserving the newly added book. If an edit cannot be reapplied without guessing the user’s intent, ask the user to resolve it. A later request can reach either worker and load the saved result.

For chat, recovery is different

1. The message service saves accepted text in persistent history. The client saves its last applied message position only after it has saved the corresponding messages locally.
2. A WebSocket server fails, ending its persistent two-way connection.
3. The client connects to another server, authenticates and asks for messages after its saved position. The old connection itself does not migrate.

Signed tokens can avoid a session lookup on every request. Their signature proves issued content was not changed, not that an hour-old permission is still current. Define token lifetime, signing-key changes and any current revocation lookup before claiming immediate permission updates.

04Choose state placement intentionally

Choose placement for a stated benefit:

• Stateless workers: use them when requests can recover required records independently, making routing, replacement and fleet changes simpler.
• Stateful workers: use them when keeping related work together has a measured benefit, such as one ordered game simulation. Explain how a replacement loads progress and prevents old-owner writes.
• Removing a stateful worker: stop new assignments, finish or save work, transfer responsibility safely, then reconnect clients. Do not start a second conflicting game owner.
• Removing a stateless worker: drain accepted requests; other workers recover saved history from its store.
• Retried purchases: statelessness alone is insufficient. Save the request key and purchase result together. Worker B can then return A's existing result after a lost response rather than buying again.

Evaluate response time, store load, session recovery and correctness separately. Calling a layer stateless is not proof that every required record survives a failure.