stateful vs. stateless protocols

Imagine two kinds of clerk. A stateful clerk remembers your previous visits: you can walk up and say "the usual, and add fries this time," and they know what "the usual" means. A stateless clerk has perfect amnesia between customers: every single time, you must state your full order from scratch, because they remember nothing about you. This is exactly the difference between a stateful and a stateless protocol — whether the server keeps memory of a client across messages.

In a stateful protocol the server maintains state about each ongoing conversation — it remembers where you are in a sequence, what you have already done, what mode you are in. FTP is stateful: after you "change directory," later commands are interpreted relative to that directory, so the server must remember it. In a stateless protocol each request is fully self-contained and the server keeps no memory between requests; the request must carry everything the server needs to act. Core HTTP is stateless: the server does not, on its own, remember that your last request logged you in. Any state (your login, your cart) must be re-supplied each time, which is exactly why cookies and tokens exist — to carry that context back on every request.

Neither choice is "better"; they trade off differently. Stateless protocols scale beautifully: because the server remembers nothing, any server in a pool can handle any request, requests can be load-balanced freely, and a crashed server loses no session memory. That simplicity and robustness is a big reason the web is stateless at its core. Stateful protocols can be more efficient and expressive for a long, ordered interaction (you set up context once and reuse it), but they tie a client to one server and make crashes and scaling harder, because that server's memory is now precious and irreplaceable. Much of modern system design is deciding which state lives where.