Dein Server hat 4 GB RAM, davon 2 GB voll mit User Sessions. 800 gleichzeitige Nutzer, jeder mit seinem Warenkorb, Login-Status, Spracheinstellung: alles im Memory. Läuft.
Dann kommt Black Friday. 8.000 Nutzer. Du brauchst einen zweiten Server. Aber User #372 hat seinen Warenkorb auf Server 1. Wenn der Load Balancer ihn auf Server 2 schickt, ist der Warenkorb weg. Also Sticky Sessions: der Load Balancer merkt sich, welcher User auf welchem Server war.
Bis Server 1 abstürzt. 400 Sessions weg. Kein Failover, weil der State nirgendwo anders existiert.
Das ist das Stateful-Problem.
Stateful
Der Server speichert den Zustand. Jede Interaktion baut auf der vorherigen auf: Sessions, Warenkörbe, WebSocket-Connections. Der Server weiß, wer du bist.
Vorteil: schnell. Alles liegt im Memory, kein Roundtrip zu einer externen DB. Für WebSocket-Verbindungen oder Gaming-Server gibt es oft keine Alternative.
Nachteil: du kannst nicht einfach einen zweiten Server daneben stellen. Die Server müssen ihren State synchronisieren oder du brauchst Sticky Sessions. Beides fragil.
Stateless
Der Server speichert nichts. Jeder Request bringt alles mit was der Server braucht: JWT Token, Session ID die auf eine externe DB zeigt, alle relevanten Parameter. Zwei identische Requests an zwei verschiedene Server liefern dasselbe Ergebnis.
Horizontal Scaling heißt: mehr Server daneben stellen statt einen Server größer machen. Funktioniert nur, wenn der einzelne Server keinen lokalen State hat, den er verlieren könnte.
Das macht Scaling trivial. Brauchst du mehr Kapazität? Neuen Server starten, Load Balancer zeigt drauf, fertig. Server stirbt? Egal, der nächste übernimmt. Kein State geht verloren, weil keiner da war.
Deshalb sind die meisten REST APIs stateless. Deshalb funktioniert Kubernetes mit beliebig vielen Replicas. Deshalb schicken SPAs bei jedem Request ein JWT mit, statt sich auf Server-Sessions zu verlassen.
Der Trade-off
Stateless heißt nicht “kein State.” Es heißt: der State lebt woanders. In Redis, in Postgres, in einem JWT. Du tauschst lokale Geschwindigkeit gegen Skalierbarkeit. Für die meisten Backend Services der richtige Deal.