Aplikacja bezstanowa (ang. stateless application) to taka, która nie przechowuje żadnych informacji o stanie klienta między kolejnymi żądaniami. Każde żądanie traktuje jak czystą kartkę: zawiera ono wszystko, co serwer musi wiedzieć, żeby je obsłużyć — kto pyta, o co pyta i z jakimi uprawnieniami. Serwer nie pamięta, że ten sam użytkownik klikał coś sekundę wcześniej. Brak tej pamięci to nie wada, tylko cecha projektowa, która bardzo ułatwia życie.
Jak to działa i po co
W aplikacji bezstanowej cały kontekst sesji ląduje albo po stronie klienta (np. w tokenie wysyłanym przy każdym żądaniu), albo w zewnętrznym, współdzielonym magazynie (baza danych, Redis). Sam proces obsługujący żądanie nie trzyma niczego w swojej pamięci RAM, co przeżyłoby między requestami. Dzięki temu nie ma znaczenia, która kopia aplikacji odpowie — każda ma dokładnie taką samą wiedzę, czyli żadną.
To otwiera drzwi do skalowania poziomego: zamiast dokładać mocy jednemu serwerowi, uruchamiasz dziesięć identycznych instancji i rozkładasz ruch load balancerem. Padnie jedna? Reszta przejmuje robotę, a użytkownik niczego nie zauważa. Restart, autoskalowanie, deploy nowej wersji — wszystko jest prostsze, bo nie martwisz się, że wraz z procesem znikną czyjeś dane logowania.
Przykład z praktyki
Klasyk to REST API z autoryzacją na JWT. Klient po zalogowaniu dostaje podpisany token i dokleja go do każdego żądania w nagłówku: Authorization: Bearer . Serwer weryfikuje podpis i wie, kim jesteś — nie musi szukać twojej sesji w pamięci. Taka aplikacja świetnie czuje się w Kubernetes, gdzie kubectl scale deployment api --replicas=10 w sekundy zwiększa liczbę kopii, a ruch jest dzielony między nie bez żadnej konfiguracji „lepkich” sesji.
Częste błędy i mity
Najczęstsza pułapka: ktoś deklaruje aplikację jako bezstanową, a po cichu trzyma sesje w pamięci procesu (np. domyślny express-session w trybie in-memory). Działa idealnie na jednej instancji, a po dołożeniu drugiej użytkownicy losowo się wylogowują, bo trafiają na kopię, która ich „nie zna”. Ratunkiem bywają sticky sessions na load balancerze, ale to plaster, nie lekarstwo — przy padzie instancji i tak tracisz stan.
Drugi mit: „bezstanowa = w ogóle nie ma stanu”. Nieprawda. Stan istnieje, tylko mieszka poza aplikacją — w bazie, cache albo tokenie. Chodzi o to, by warstwa aplikacyjna była wymienna, a nie żeby dane wyparowały.
Pojęcia powiązane
Warto skojarzyć to z: aplikacja stanowa (stateful), skalowanie poziome, load balancer, sticky sessions, JWT, REST, dwunastoczynnikowa aplikacja (12-factor app) oraz Redis jako zewnętrzny magazyn sesji.