Stateless vs stateful
Un système stateless ne garde aucune trace de ce qui s'est passé avant : chaque requête repart de zéro. Un système stateful se souvient (session de connexion, panier, historique de conversation). La distinction commande cinq couples d'architecture que tout builder IA finit par devoir trancher : Lambda contre ECS (tâche ponctuelle qui se déclenche contre service qui tourne en continu), base de données contre cache (stockage durable contre copie rapide et temporaire), file d'attente contre flux (liste qu'on vide une fois traitée contre timeline d'événements qu'on rejoue), récupération contre reclassement (retrouver un lot de documents contre remonter les meilleurs en tête), surveillance contre traçage (savoir que quelque chose cloche contre suivre une requête pour trouver où). Quelques repères concrets rendent chaque couple lisible. Lambda sert une tâche courte déclenchée par un événement, comme traiter un fichier au moment où il est déposé ; ECS fait tourner un service qui doit rester allumé, comme une API, et peut porter aussi bien du stateless que du stateful. Une file d'attente ressemble aux bons de commande d'une cuisine : un cuisinier prend un bon, le prépare, et le bon disparaît de la liste. Un flux ressemble plutôt au registre de tout ce qui s'est passé : l'événement reste, et plusieurs systèmes peuvent le relire chacun de leur côté sans se gêner. Le cache, lui, est une copie des données les plus demandées posée sur une mémoire rapide, jamais l'original. **C'est aussi ce qui fixe l'ordre de montée en charge d'une app.** Cet ordre compte cinq marches, pas deux. Plusieurs applis sur le même VPS à quelques euros ; puis l'appli qui a des utilisateurs sur son propre serveur, pour qu'elle ne tombe plus à cause d'une voisine ; puis la séparation, la base sur sa machine, le front et le back chacun sur la sienne, ce qui montre enfin quelle partie consomme ; puis le scaling vertical, une machine plus grosse pour cette partie-là, qui tourne à vide la nuit ; enfin le scaling horizontal, plusieurs copies derrière un load balancer. La troisième marche vient avant la cinquième pour une raison stateless : dès que tu dupliques un serveur, plus rien ne peut vivre dessus. Les données partent en base, les fichiers déposés par les utilisateurs sur un stockage de fichiers, et les sessions dans la base ou un cache partagé, sinon l'utilisateur est déconnecté chaque fois que le load balancer l'envoie sur une autre copie. Et l'ordre sert aussi dans l'autre sens : trois serveurs pour zéro utilisateur, c'est payer une archi pour un trafic qui n'existe pas.
Forces
- Un seul axe de lecture qui range cinq décisions d'archi au lieu de les traiter une par une
- Le réflexe stateless-par-défaut évite la dette de scalabilité la plus courante
Limites
- La distinction est binaire en théorie mais floue en pratique : beaucoup de systèmes sont stateful par endroits seulement
Pour qui
- Un dev ou tech lead qui pose les fondations d'un backend IA et veut éviter de payer une archi naïve plus tard