„Stateless“ klingt nach einem Begriff für Architekturfolien. Dahinter steckt eine sehr praktische Frage. Was passiert, wenn dieselbe Anwendung zweimal gleichzeitig läuft?
Das Problem entsteht bei der zweiten Instanz
Solange ein Backend genau einmal läuft, kann es sich alles Mögliche merken. Wer angemeldet ist. Was im Warenkorb liegt. An welcher Stelle eines mehrstufigen Formulars jemand steht. All das lässt sich im Speicher des Prozesses ablegen, und es funktioniert tadellos.
Bis eine zweite Instanz dazukommt. Ein Loadbalancer verteilt die Anfragen, und der zweite Server weiß nichts von dem, was der erste sich gemerkt hat. Benutzer werden scheinbar zufällig abgemeldet, halb ausgefüllte Formulare verschwinden, und niemand kann den Fehler zuverlässig nachstellen.
Denselben Effekt erzeugt übrigens schon ein Neustart. Wer nach jedem Deployment Anrufe bekommt, weil Leute aus der Sitzung geflogen sind, hat das Problem längst, ohne je skaliert zu haben.
Was zustandslos konkret bedeutet
Zwischen zwei Aufrufen behält der Serverprozess nichts. Alles, was über einen Aufruf hinaus gelten soll, liegt an einem Ort, den jede Instanz erreicht.
- Anmeldung über ein Token, das der Client mitschickt, oder über eine Sitzung, die in Datenbank oder Zwischenspeicher liegt statt im Dateisystem eines Servers.
- Zwischenstände in der Datenbank, nicht im Speicher.
- Hochgeladene Dateien in einem gemeinsamen Ablageort, nicht auf der lokalen Platte einer Instanz.
- Hintergrundarbeit in einer Warteschlange, die alle Instanzen bedienen können.
Für jeden dieser Punkte bringt Laravel einen vorgesehenen Weg mit. Die Arbeit besteht kaum darin, etwas zu bauen. Sie besteht darin, die bequemen Abkürzungen liegen zu lassen.
Was es kostet
Ehrlich gesagt etwas mehr Disziplin und etwas mehr Infrastruktur. Ein gemeinsamer Zwischenspeicher will betrieben werden, ein gemeinsamer Dateispeicher auch. Und jede Stelle, an der jemand doch etwas lokal ablegt, wird zur Zeitbombe, die erst unter Last hochgeht.
Dafür hört Wachstum auf, ein Umbau zu sein. Mehr Last heißt mehr Instanzen. Fällt eine aus, übernimmt die nächste. Ein Deployment wirft niemanden aus der Sitzung. Der Ausfall einer einzelnen Maschine ist dann kein Ereignis mehr, sondern eine Zeile im Protokoll.
Und wenn es doch schnell gehen muss
Nicht jede Anfrage lässt sich in wenigen Millisekunden beantworten. Ein PDF-Export, ein Aufruf bei einem fremden System, ein Mailversand an tausend Empfänger. So etwas gehört in eine Warteschlange. Der Aufruf legt einen Auftrag ab und antwortet sofort, ein Hintergrundprozess arbeitet ihn später ab.
Der angenehme Nebeneffekt zeigt sich, wenn das fremde System gerade streikt. Dann hängt nicht die Anfrage des Benutzers, sondern nur der Auftrag. Und der kann es in zehn Minuten noch einmal versuchen.
Mehr dazu, wie wir Schnittstellen schneiden, steht unter API- und Backend-Entwicklung.
