Julien Esnault
Lesson 04 · Architecture

Stateless vs Stateful: Memory vs Amnesia

To build giant systems (like Netflix or Uber), your servers must suffer from amnesia. It seems counter-intuitive, but forgetting who the user is at every request is the secret to infinite scalability. Welcome to the world of Stateless.

1

The Duel: The Local Bartender vs McDonald's

Stateful (With Memory)
The Local Bartender Analogy:
You walk in, he smiles: "The usual?". He knows your history, your name, and how many drinks you've had.
Problem: If this bartender is sick, the replacement knows nothing about you. You have to explain everything again.
  • Simple to code initially (variables in memory).
  • Hard to scale: the user is "married" to a specific server (Sticky Session).
Stateless (No Memory)
The Fast-Food Analogy:
At the counter, they don't know you. You must provide your order number every time.
Advantage: Any employee can serve you. If one register closes, you can go to another without issues.
  • Infinite scalability: any server can process the request.
  • Resilient: if a server crashes, no data is lost (since it stored nothing).
2

Visualization

Stateless vs Stateful Diagram
Left (Stateful): The server keeps context. Right (Stateless): The context is stored externally (DB/Redis) or on the client side.
3

Comparison Table

CriteriaStatefulStateless
Where is the data?In the server's memory (RAM)Database, Cache (Redis), or Client
If server crashes?User gets logged out (session loss)No impact, another server takes over
ScalabilityComplex (Needs "Sticky Sessions")Easy (Horizontal Scaling)
4

The Secret: "Stateless" doesn't mean dataless!

Externalizing State

This is the most common confusion. A Stateless application NEEDS state (cart, logged-in user).
The difference is that the application server does not keep this state on itself. It pushes it to a dedicated service:

1. Redis (for temporary sessions).
2. PostgreSQL/MySQL (for durable data).

Thus, the application server becomes a simple interchangeable "processor".

5

Classic Traps

The "Sticky Sessions" Trap

If you choose a Stateful architecture, you must configure your Load Balancer to always send Client IP 123 to Server A. This is fragile and creates load imbalances.

Storing images locally

Beginner mistake: uploading a user's avatar to the server's hard drive. If the next request arrives at another server, the image will be "not found".
Solution: External Object Storage (AWS S3).

6

In Interviews (The System Design Interview)

The Golden Rule

By default, always design a Stateless architecture for the Web/API layer.

The Magic Sentence:"I design my API services as Stateless to allow easy Horizontal Auto-Scaling. I will store session state in a shared Redis cluster."
The Exception:Real-time systems like multiplayer video games or WebSockets (Chat) are often Stateful because maintaining a persistent open connection is necessary for latency.
7

Flash Quiz

Self-Evaluation
8

Your Turn

Mission: Make this system Stateless

Currently, the user connects to Server A. Server A keeps "User=Connected" in its RAM.
If the next request arrives at Server B, the user is rejected.

Your mission: Draw an external component (e.g., Redis) and show how Servers A and B can use it to share information.

9

For the Curious (Bonus)

JWT (JSON Web Token)
This is the ultimate Stateless weapon. Instead of storing the session in a server-side database, we give all the info (ID, Role, Expiration) to the client in an encrypted token. The client sends this token with every request. The server doesn't even need to look in the database, it just checks the signature!
Cattle vs Pets
A famous DevOps analogy.
Stateful (Pets): We give them names (Zeus, Apollo). If they get sick, we nurse them back to health.
Stateless (Cattle): They have numbers (s001, s002). If they get sick, we replace them with new ones. It's cruel, but that's the Cloud!