Stateless vs Stateful : Mémoire vs Amnésie
Pour construire des systèmes géants (comme Netflix ou Uber), vos serveurs doivent souffrir d'amnésie. Cela semble contre-intuitif, mais oublier qui est l'utilisateur à chaque requête est le secret d'une scalabilité infinie. Bienvenue dans le monde du Stateless.
Le Duel : Le Barman Habitué vs Le McDo
Vous entrez, il vous sourit : "Comme d'habitude ?". Il connait votre historique, votre nom, et où vous en êtes.
Problème : Si ce barman est malade, le remplaçant ne sait rien de vous. Vous devez tout réexpliquer.
- Simple à coder au début (variables en mémoire).
- Difficile à scaler : l'utilisateur est "marié" à un serveur spécifique (Sticky Session).
Au comptoir, on ne vous connait pas. Vous devez donner votre numéro de commande à chaque fois.
Avantage : N'importe quel employé peut vous servir. Si une caisse ferme, vous allez à l'autre sans souci.
- Scalabilité infinie : n'importe quel serveur peut traiter la requête.
- Résilient : si un serveur crashe, aucune donnée n'est perdue (car il ne stockait rien).
Visualisation
Tableau Comparatif
| Critère | Stateful | Stateless |
|---|---|---|
| Où est la donnée ? | Dans la mémoire (RAM) du serveur | Base de données, Cache (Redis) ou Client |
| Si le serveur crash ? | L'utilisateur est déconnecté (perte de session) | Aucun impact, un autre serveur prend le relais |
| Scalabilité | Complexe (Besoin de "Sticky Sessions") | Facile (Horizontal Scaling) |
Le Secret : "Stateless" ne veut pas dire sans données !
L'externalisation de l'État
C'est la confusion la plus courante. Une application Stateless A BESOIN de l'état (panier, utilisateur connecté).
La différence, c'est que le serveur d'application ne garde pas cet état sur lui. Il le pousse vers un service dédié :
1. Redis (pour les sessions temporaires).
2. PostgreSQL/MySQL (pour les données durables).
Ainsi, le serveur d'application devient un simple "processeur" interchangeable.
Les Pièges Classiques
Si vous choisissez une architecture Stateful, vous devez configurer votre Load Balancer pour qu'il renvoie toujours le client IP 123 vers le Serveur A. C'est fragile et cela crée des déséquilibres de charge.
Erreur de débutant : uploader l'avatar d'un utilisateur sur le disque dur du serveur. Si la prochaine requête arrive sur un autre serveur, l'image sera "introuvable".
Solution : Stockage Objet externe (AWS S3).
En Entretien (Le "System Design Interview")
Par défaut, dessinez toujours une architecture Stateless pour la couche Web/API.
Flash Quiz
À toi de jouer
Mission : Rendre ce système Stateless
Actuellement, l'utilisateur se connecte sur le Serveur A. Le Serveur A garde "User=Connecté" dans sa RAM.
Si la requête suivante arrive sur le Serveur B, l'utilisateur est rejeté.
Ta mission : Dessine un composant externe (ex: Redis) et montre comment les Serveurs A et B peuvent l'utiliser pour partager l'information.
Pour les curieux (Bonus)
Stateful (Pets) : On leur donne des noms (Zeus, Apollo). S'ils sont malades, on les soigne.
Stateless (Cattle) : Ils ont des numéros (s001, s002). S'ils sont malades, on les remplace par des nouveaux. C'est cruel, mais c'est le Cloud !