Stop 01 · Internet & Backend BasicsTopics · 8/15

Statelessness

In short

Your app goes viral and one server isn't enough, so you run five. If any server remembers users in its own memory, logins start failing at random. Stateless servers fix that.

The REST constraint that each request must contain all the information needed to process it — the server shouldn't rely on memory of previous requests.

The mascot scans a tag on a car windscreen at one of several identical toll booths.

Think of it like this

FASTag at the toll plaza

No toll booth remembers your car. The tag on your windscreen carries everything needed, so any lane can scan it and let you through. A stateless server works the same way: every request carries its own proof, so any server can handle it.

Watch it happen

Any server can answer

Client

Load balancer

Server A

Server B

GET /me + token

1/7Riya's app sends a request with her login token in the Authorization header.

The big ideas

What you need to know

Each request is complete

A request carries everything the server needs: who you are (token or cookie) and what you want (URL, body).

State lives in shared stores

User data, sessions and carts go in a database or Redis that every server can reach, never in one process's memory.

Easy to scale and restart

Any server can be added, removed or restarted without logging anyone out.

HTTP itself forgets

HTTP is stateless by design. Logins are built on top using cookies or tokens sent with every request.

See it in code

Walk through the code

1import jwt from "jsonwebtoken";2// Breaks with 2+ servers: this Set lives in one process only3const loggedIn = new Set();4app.post("/login-bad", (req, res) => {5  loggedIn.add(req.body.userId);6  res.sendStatus(204);7});8// Works on any server: each request proves who it is9app.get("/me", (req, res) => {10  const token = req.headers.authorization?.replace("Bearer ", "");11  try {12    res.json({ id: jwt.verify(token, process.env.JWT_SECRET).sub });13  } catch {14    res.sendStatus(401);15  }16});

1/3Login state in a Set exists only inside this one process. Another server, or a restart, loses it.

jsonwebtoken checks the token's signature with a shared secret, so every server can verify it without asking the others. Sessions stored in Redis are the other common stateless setup.

Save yourself the pain

Common mistakes

Oops

Keeping sessions in memory or uploaded files on one server's local disk.

Do this instead

Put sessions in Redis or a database and files in object storage, so any server can handle any request.

Oops

Thinking 'stateless' means your app has no data.

Do this instead

The data still exists. It just lives in shared stores, not inside one server process.

Your mission

Break it, then fix it

~30 min

Quick check

You run three copies of your API behind a load balancer and keep shopping carts in a JavaScript object. What do users notice?

Go deeper

1Identify what data a stateless API must include in every request (e.g. auth tokens).
2Learn why statelessness is what makes APIs horizontally scalable.
3Compare a stateless REST API to a stateful, session-based server.