So halten Sie Anwendungen zustandslos

Dies mag eine verwickelte Frage sein, aber ich versuche, die Staatenlosigkeit besser zu verstehen.

Basierend auf dem, was ich gelesen habe, sollten Webanwendungen statusfrei sein, was bedeutet, dass jede Anfrage als unabhängige Transaktion behandelt wird. Aus diesem Grund sollten Sitzung und Cookies vermieden werden (da beide zustandsbehaftet sind). Ein besserer Ansatz ist die Verwendung von Tokens, die zustandslos sind, da auf dem Server nichts gespeichert ist.

Ich versuche zu verstehen, wie Webanwendungen statusfrei sein können, wenn Daten für meine Sitzung gespeichert werden (z. B. Artikel in einem Warenkorb). Werden diese tatsächlich irgendwo in einer Datenbank gespeichert und dann regelmäßig gelöscht? Wie funktioniert das, wenn Sie ein Token anstelle von Cookies verwenden?

Und sind die wichtigsten Websites (Amazon, Google, Facebook, Twitter usw.) tatsächlich zustandslos? Verwenden sie Token oder Cookies (oder beides)?

"Webanwendungen sollten statusfrei sein" sollte als "Webanwendungen sollten statusfrei sein, es sei denn, es gibt einen sehr guten Grund, einen Status zu haben" verstanden werden . Ein "Einkaufswagen" ist von Natur aus ein zustandsbehaftetes Merkmal, und das zu leugnen ist ziemlich kontraproduktiv. Der springende Punkt des Warenkorbmusters besteht darin, den Status der Anwendung zwischen den Anforderungen beizubehalten.

Eine Alternative, die ich mir als zustandslose Website vorstellen könnte , die einen Warenkorb implementiert, wäre eine einseitige Anwendung, die den Warenkorb vollständig clientseitig verwaltet, Produktinformationen mit AJAX-Aufrufen abruft und diese dann auf einmal an den Server sendet Der Benutzer führt einen Checkout durch. Ich bezweifle jedoch, dass ich jemals jemanden gesehen habe, der dies tatsächlich tut, da der Benutzer nicht mehrere Browser-Registerkarten verwenden kann und den Status nicht beibehält, wenn er die Registerkarte versehentlich schließt. Sicher, es gibt Workarounds wie die Verwendung von localstorage, aber dann haben Sie wieder state, nur auf dem Client statt auf dem Server.

Wenn Sie eine Webanwendung haben, bei der Daten zwischen Seitenaufrufen beibehalten werden müssen, führen Sie normalerweise Sitzungen ein. Die Sitzung, zu der eine Anfrage gehört, kann entweder durch ein Cookie oder durch einen URL-Parameter identifiziert werden, den Sie jedem Link hinzufügen. Cookies sollten bevorzugt werden, da sie Ihre URLs handlicher halten und verhindern, dass Ihr Benutzer versehentlich eine URL mit der darin enthaltenen Sitzungs-ID weitergibt. Das Vorhandensein von URL-Tokens als Fallback ist jedoch auch für Benutzer von entscheidender Bedeutung, die Cookies deaktivieren. Die meisten Webentwicklungs-Frameworks verfügen über ein Session-Handling-System, das dies sofort erledigt.

Auf der Serverseite werden Sitzungsinformationen normalerweise in einer Datenbank gespeichert. Server-seitiges In-Memory-Caching ist optional. Die Reaktionszeit kann erheblich verkürzt werden, Sie können jedoch keine Sitzungen zwischen verschiedenen Servern übertragen. Sie benötigen also eine persistente Datenbank als Fallback.

Sind die wichtigsten Websites (Amazon, Google, Facebook, Twitter usw.) tatsächlich zustandslos? Verwenden sie Token oder Cookies (oder beides)?

Erlauben sie dir, dich einzuloggen? Wenn Sie dann die Registerkarte schließen und die Site erneut besuchen, sind Sie immer noch angemeldet? In diesem Fall verwenden sie Cookies, um Ihre Identität zwischen den Sitzungen zu wahren.

Es ist wahr, dass Webanwendungen statusfrei sein sollten. Sitzungsvariablen, Cookies und Token verletzen dies jedoch nicht, wenn sie alle auf dem Client (Webbrowser) gespeichert sind. Sie können Parameter in der Anfrage sein.

Hier ist ein vereinfachtes Modell:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

Dies könnte für Software Engineering Stack Exchange funktionieren . Diese Antwort, die ich schreibe, ist Teil des Status meines Webbrowsers. Solange das der einzige Ort ist, an dem es ist, ist es niemandem außer mir zugänglich. Sobald ich aber Post your Answerdrücke, schickt mein Browser es an den Webserver. Der Webserver verarbeitet den Beitrag ohne eigenen Status. Es erfährt von meinem Browser und aus der Datenbank, wer ich bin. Sobald mein Beitrag überprüft und zur Datenbank hinzugefügt wurde, vergisst der Webserver umgehend, dass ich angemeldet bin.

Das bedeutet Staatenlos. Der Server ist nicht dafür verantwortlich, sich daran zu erinnern. Das ist nicht seine Aufgabe.

Dies zu tun hat viele Vorteile. Wenn auf dem Webserver ein Speicherverlust auftritt, ist dies erkennbar, da der Speicherbedarf nicht zunehmen sollte. Wenn der Webserver abstürzt, passt meine Identität nicht dazu. Wenn jemand versucht, einen Denial-of-Service-Angriff durchzuführen, kann er keine Ressourcen für den Webserverstatus verwenden, da der Webserver zwischen den Sitzungen keinen Status für ihn zuweist. Dies alles zielt darauf ab, den Webserver stabil zu machen. Auf diese Weise läuft es weiter, wenn es anfängt zu laufen.

Sicher, ich verbrauche Ressourcen in der Datenbank, aber diese Ressourcen wurden zuerst durch etwas Stabiles, auf das wir uns verlassen können, um die Datenbank vor dem wilden und wolligen Web zu schützen, auf dem zustandslosen, die Geschäftsregeln erzwingenden Webserver, auf meine Zulässigkeit überprüft.

Webanwendungen sollten statusfrei sein

Unsinn. Web - Anfragen sollten staatenlos sein. Oder genauer gesagt, Web - Anfragen sind staatenlos.

Aber zu sagen, dass eine ganze Anwendung zustandslos sein sollte, ist völliger Unsinn.

Jede Anfrage wird als unabhängige Transaktion behandelt.

Ja, genau . Oder genauer gesagt, ja, unbedingt . Über HTTP ist jede Anforderung von Natur aus unabhängig von allen anderen Anforderungen. Zum Hinzufügen von "statefulness" zu HTTP müssen Sie "state" für jede "stateful" -Anforderung explizit identifizieren, speichern und abrufen. Das kostet Mühe, verringert die Leistung und erhöht die Komplexität.

Und aus diesen Gründen sollte jede Anfrage, die zustandslos sein kann , zustandslos sein.

Aus diesem Grund sollten Sitzung und Cookies vermieden werden (da beide zustandsbehaftet sind). Ein besserer Ansatz ist die Verwendung von Tokens

Ein paar Dinge: Tokens können auch an den Sitzungsspeicher gebunden werden. Cookies nicht brauchen , um Sitzungsspeicher gebunden werden. Tokens werden oft in Cookies gespeichert. Und manchmal ist eine Sitzung einfach das richtige Werkzeug für den Job.

Das bedeutet, dass Sitzungen und Cookies zumindest manchmal genauso "besser" sind wie Token!

[Tokens] sind zustandslos, da auf dem Server nichts gespeichert ist.

Das war's. Darum geht es im Dogma der Staatenlosigkeit wirklich. Es geht jedoch nicht darum, "nichts" auf dem Server zu speichern, sondern darum, den Sitzungsstatus nicht auf dem Server zu speichern .

Mein Google Mail-Posteingang befindet sich beispielsweise in einem Status. Und es ist verdammt noch mal besser , auf dem Server gespeichert zu werden! Es ist jedoch kein Sitzungsstatus .

Anstatt einen Server zu haben, der eine kleine Kennung hat und herausfindet, wer Sie sind und so weiter, möchten zustandslose Anwendungen bei jeder verdammten Anfrage daran erinnert werden, wer Sie sind und was Sie tun . Der Anwendungsstatus ist noch vorhanden, der Client ist nur dafür verantwortlich, ihn zu behalten.

Wenn dieser Zustand klein ist, ist das wahrscheinlich in Ordnung. In einigen Fällen ist es sehr gut.

Und dann gibt es natürlich Dinge, von denen wir einfach erwarten, dass sie zustandsmäßig sind ...

Wie können Webanwendungen statusfrei sein, wenn Daten für meine Sitzung gespeichert werden (z. B. Artikel in einem Warenkorb)? Werden diese tatsächlich irgendwo in einer Datenbank gespeichert und dann regelmäßig gelöscht?

Zwei Optionen. Entweder haben Sie eine Sitzung oder Sie sind in Ablehnung!

... Aber ernsthaft. Normalerweise würden Sie einen Einkaufswagen nicht in einem Cookie speichern. So etwas wie ein Einkaufswagen wird entweder in einer "herkömmlichen" Sitzung oder als CartObjekt mit einer ID gespeichert , mit der der Server ihn für nachfolgende Anforderungen abruft. Irgendwie wie eine ... äh ... ähm ... Sitzung.

Im Ernst: In hohem Maße ist "Statefulness" genau das, was wir nennen, wenn zwei Kommunikationsagenten Nachrichten in einem Gespräch kontextualisieren können. Und eine Sitzung, die traditionell verstanden wird, ist genau das, was wir normalerweise den Mechanismus nennen, durch den dies geschieht.

Ich würde argumentieren, dass Sie, unabhängig davon, ob Sie Token oder "Sitzungen" verwenden, für jede Anforderung, die Ihr Server verarbeitet, diese Anforderung entweder kontextualisieren müssen, um sie zu erfüllen, oder nicht. Wenn der Kontext nicht erforderlich ist, holen Sie ihn nicht ab. Wenn der Kontext ist notwendig, Sie es besser in der Nähe haben!

Und sind die wichtigsten Websites (Amazon, Google, Facebook, Twitter usw.) tatsächlich zustandslos? Verwenden sie Token oder Cookies (oder beides)?

Wahrscheinlich beides. Aber im Allgemeinen tun sie genau das, was Sie tun: Sie setzen Cookies, um "Status" -Datensätze in umfangreichen "Sitzungs" -Datenbanken zu identifizieren.

Wenn möglich, vermute ich, dass sie grundlegende Identitätsansprüche in kurzlebige "Token" verwandeln, um unnötige Konflikte bei der zentralen Speicherung zu vermeiden. Die Tatsache, dass ich mich bei vielen dieser Dienste von allen anderen Standorten abmelden kann, ist jedoch ein guter Indikator dafür, dass sie, wenn sie überhaupt Token verwenden, zumindest von einem semi-traditionellen Sitzungsmodell "unterstützt" werden .

Statefulness ist nicht unbedingt eine schlechte Sache, aber Sie müssen den Unterschied zwischen stateful und zustandslosen Apps verstehen. Kurz gesagt, in statusbehafteten Apps werden Informationen zur aktuellen Sitzung gespeichert, in statusbehafteten Apps jedoch nicht. Informationen, die permanent als Teil eines Benutzerkontos gespeichert werden, können in einer Sitzung gespeichert werden oder auch nicht, aber das Speichern von Informationen in Bezug auf ein Benutzerkonto macht die Anwendung nicht automatisch statusbehaftet. Statefulness erfordert, dass der Server Informationen über die Sitzung des aktuellen Benutzers verwaltet, die über die des Client-Browsers hinausgehen. Ein Client könnte sich beispielsweise authentifizieren und ein JSESSIONID-Cookie erhalten, das er dann bei jeder Anforderung an den Server sendet. Wenn der Server mit dem Speichern von Inhalten im Sitzungsbereich der Anwendung beginnt, die auf dieser JSESSIONID basieren, wird der Zustand wiederhergestellt.

Staatenlosigkeit

Mit zustandslos ist gemeint, dass Server und Client keine aktuellen Informationen über die Benutzersitzung verwalten. Der Client und der Server können eine Form von Token verwenden, um die Authentifizierung zwischen Anforderungen bereitzustellen, es werden jedoch keine anderen aktuellen Informationen gespeichert. Ein typischer Anwendungsfall für eine solche Lösung könnte eine Nachrichten-Site sein, auf der die meisten Benutzer (neue Verbraucher) Informationen konsumieren, aber keine Informationen produzieren, die auf die Site zurückgehen. In solchen Fällen muss die Site keine Informationen über die aktuelle Benutzersitzung verwalten. Beachten Sie, dass die Website möglicherweise immer noch Cookies verwendet, um den Benutzer zu identifizieren und Informationen über die Verwendung der Website durch den Benutzer zu speichern. Dies kann jedoch weiterhin als zustandslos angesehen werden, da alles, was aufgezeichnet wurde, eine Transaktion sein kann, z der Server, aber nicht in einer Benutzersitzung verwaltet.

Statefulness auf dem Server

Auf dem Server speichert eine Stateful-App Statusinformationen zu aktuellen Benutzern. Bei diesem Ansatz werden in der Regel Cookies verwendet, um das System des Benutzers zu identifizieren, sodass der Status zwischen Anforderungen auf dem Server beibehalten werden kann. Sitzungen können je nach Anwendungskontext authentifiziert werden oder nicht. Stateful-Server-Apps bieten den Vorteil, dass Benutzerzustandsinformationen auf dem Server zwischengespeichert werden und Lookups und Seitenantwortzeiten beschleunigt werden. Andererseits ist das Speichern von Informationen im Sitzungsbereich teuer und wird im Maßstab sehr ressourcenintensiv. Es schafft auch einen potenziellen Angriffsvektor für Hacker, mit dem sie versuchen können, Sitzungskennungen zu hijacken und Benutzersitzungen zu stehlen. Stateful Server-Apps haben auch die Herausforderung, Benutzersitzungen vor unerwarteten Dienstunterbrechungen, z. B. einem Serverausfall, zu schützen.

Statefulness auf dem Klienten

Mithilfe von JavaScript und modernen Browsertechnologien wie sessionStorage kann die Anwendung jetzt problemlos Statusinformationen zu einer Benutzersitzung auf dem Gerät des Benutzers speichern. Insgesamt kann die Anwendung immer noch als statusbehaftet angesehen werden, die Aufgabe der Statusverwaltung wurde jedoch auf den Client verlagert. Dieser Ansatz hat einen großen Vorteil (für den Betreuer der Webanwendung) gegenüber der Aufrechterhaltung des Status auf dem Server, da jeder Benutzer seinen eigenen Status aufrechterhält und die Serverinfrastruktur nicht belastet wird. Im Internet hat diese Art der Architekturauswahl enorme Auswirkungen auf die Hardware- und Stromkosten. Es könnte buchstäblich Millionen von Dollar pro Jahr kosten, den Status auf dem Server aufrechtzuerhalten. Durch den Wechsel zu einem System, das den Status des Clients beibehält, können dann jährlich Millionen von Dollar eingespart werden.

Tokens v. Cookies

Cookies dienen als Bezeichner für Clientgeräte / Browser. Sie können verwendet werden, um alle möglichen Dinge zu speichern, aber im Allgemeinen speichern sie eine Art von Bezeichner, wie z. B. CFID / CFTOKEN in CFML-Apps. Cookies können so eingestellt werden, dass sie für längere Zeit im Browser des Benutzers gespeichert bleiben. Dies ermöglicht es beispielsweise, die Authentifizierung in einer App zwischen Browsersitzungen aufrechtzuerhalten. Cookies können auch auf Nur-Speicher gesetzt werden, sodass sie verfallen, wenn ein Benutzer den Browser schließt.

Bei Tokens handelt es sich im Allgemeinen um eine Art identifizierender Informationen über den Benutzer, die auf dem Server generiert (mithilfe von Verschlüsselung zum Verwürfeln der Informationen), an den Client übergeben und mit der nachfolgenden Anforderung an den Server zurückgegeben werden. Sie können im Header der Anforderung und der Antwort übergeben werden, was in Anwendungen mit nur einer Seite ein gängiges Muster ist. Im Idealfall wird bei jeder Anforderung / Antwort ein neues Token generiert, sodass Token nicht abgefangen und später von einem Angreifer verwendet werden können.

Single Page Apps und Clientstatus

Bei SPAs werden Statusinformationen in den Client-Browser geladen und dort verwaltet. Wenn sich der Status ändert, z. B. wenn Sie eine Aktualisierung auf Ihrem Social Media-Konto veröffentlichen, leitet der Client diese neue Transaktion an den Server weiter. In diesem Fall speichert der Server das Update in einem dauerhaften Datenspeicher wie einer Datenbank und leitet alle Informationen an den Client zurück, die er für die Synchronisierung mit dem Server basierend auf dem Update benötigt (z. B. eine ID für das Update).

Beachten Sie, dass dieses Muster des Speicherns des Status auf dem Client Vorteile für Online- / Offline-Erlebnisse bietet, da Sie vom Server getrennt werden können, während Sie noch eine einigermaßen verwendbare Anwendung haben. Twitter ist ein gutes Beispiel für diesen Fall, in dem Sie alle geladenen Clientseiten in Ihrem Twitter-Feed überprüfen können, auch wenn Sie nicht mit der Twitter-Server-App verbunden sind. Dieses Muster schafft auch Komplexität bei der Synchronisation zwischen Server und Client, was ein ganz eigenes Thema ist. Die Komplexität der Lösung ist ein Kompromiss für die Aufrechterhaltung des Status auf dem Client.

Durch die Statefulness auf dem Client fühlen und verhalten sich Web-Apps eher wie herkömmliche Desktop-Apps. Im Gegensatz zu Desktop-Apps werden in der Regel nicht alle Kontoinformationen in einem Browser in Ihre Clientsitzung geladen. Dies wäre in vielen Fällen unpraktisch und würde zu schlechten Erfahrungen führen. Können Sie sich vorstellen, ein ganzes Google Mail-Postfach in den Browser zu laden? Stattdessen verwaltet der Client Informationen wie das Label / den Ordner, den Sie suchen, und wo in der Liste der E-Mails in dem Ordner, den Sie suchen. Das Abwägen der zu pflegenden Statusinformationen und der erforderlichen Anforderungen ist eine weitere technische Herausforderung dieses Musters. Auch hier besteht ein Kompromiss zwischen Praktikabilität und der Bereitstellung einer guten Benutzererfahrung.

Einkaufswagen und dergleichen

Was Besonderheiten wie Einkaufswagen betrifft, kommt es wirklich auf die Lösung an. Ein Einkaufswagen kann in einer Datenbank auf dem Server gespeichert sein, er kann nur im Sitzungsbereich auf dem Server gespeichert sein oder er kann sogar auf dem Client gespeichert sein. Amazon bietet beständige Warenkörbe für angemeldete Benutzer und "temporäre" Warenkörbe für anonyme Benutzer an, obwohl diese Warenkörbe zu einem gewissen Grad beständig sind.

Wenn Sie über etwas wie Google sprechen, bei dem es sich in Wirklichkeit um eine Reihe verschiedener Anwendungen handelt, die unter derselben Marke laufen, haben sie wahrscheinlich keine gemeinsame Architektur und sind so aufgebaut, dass sie den Bedürfnissen ihrer Benutzer am besten entsprechen. Wenn Sie erfahren möchten, wie eine Website erstellt wird, öffnen Sie die Entwicklertools in Ihrem Browser und schauen Sie sich diese an. Suchen Sie nach Cookies, beobachten Sie den Netzwerkverkehr und sehen Sie, wie er ausgeführt wird.

Tut mir leid, wenn diese Antwort ein wenig verwirrt, aber Staatlichkeit ist ein komplexes Thema.

Sitzungen und Cookies müssen nicht vermieden werden. Sie können sie weiterhin mit zustandslosen Webanwendungen verwenden.

Es gibt einen großen Unterschied zwischen Java und Ruby on Rails. Java-Apps speichern die Sitzung mithilfe eines in einem Cookie gespeicherten Sitzungsschlüssels im Speicher. So können Sie schnell den Benutzerstatus und den Warenkorb abrufen. Sie müssen jedoch immer denselben Server mit Ihrer Sitzung treffen.

Rails-Apps speichern die Benutzer-ID in einem signierten, verschlüsselten Cookie. Es kann nicht manipuliert werden. Wenn Sie eine Seite laden, ruft die Web-App Ihren Status, Ihren Benutzer und Ihren Einkaufswagen aus einer Datenbank ab. Dies ist langsamer, aber der Schlüssel ist, dass Sie jede Instanz treffen können ! Auf diese Weise können Sie Instanzen nach Belieben neu starten, skalieren und herunterfahren. Sehr angenehm. Mit einer gemeinsam genutzten speicherinternen Cachedatenbank wie Redis kann dies ebenfalls beschleunigt werden. Sie können den Einkaufswagen auch im Cookie speichern, sofern er klein genug ist.

So können Sie durch clevere Techniken Staatenlosigkeit erreichen und die Fähigkeit hinzufügen, nach Belieben zu skalieren.

Das Protokoll ist zustandslos.

Daraus folgt jedoch nicht unbedingt, dass Anwendungen, die das Protokoll verwenden, zustandslos sein sollten.

Hier einige verwandte StackOverflow-Antworten, die den Unterschied gut erklären:

• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34678600#34678600
• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34677668#34677668

Wenn Sie auf statuslos verweisen, z. B. in einem RESTful HTTP-Dienst, vermeiden Sie das Speichern des Status auf der Serverseite. Dazu gehört im besten Fall auch, dass Sie keinen Status in einer Datenbank oder anderen dauerhaften Speichern im Backend speichern. Um es deutlich zu machen, spreche ich von einem Zustand, der im Allgemeinen keine Daten ist. Es scheint, dass einige Leute die Dinge durcheinander bringen.

Eine zustandslose Kommunikation bietet mehrere Vorteile, insbesondere in Bezug auf Skalierbarkeit und Verfügbarkeit.

Ein besserer Ansatz ist die Verwendung von Tokens, die zustandslos sind, da auf dem Server nichts gespeichert ist.

Das stimmt (für bestimmte Authentifizierungs- und Autorisierungsprotokolle). Tokens können (aber nicht per se) alle Informationen innerhalb der Anforderung bereitstellen, die zur Authentifizierung eines Benutzers oder zur Autorisierung einer Aktion erforderlich sind. Ein Beispiel ist JWT .

Ich versuche zu verstehen, wie Webanwendungen statusfrei sein können, wenn Daten für meine Sitzung gespeichert werden (z. B. Artikel in einem Warenkorb). Werden diese tatsächlich irgendwo in einer Datenbank gespeichert und dann regelmäßig gelöscht? Wie funktioniert das, wenn Sie ein Token anstelle von Cookies verwenden?

Zum Warenkorb Beispiel. Es ist kein Problem, alle Einkaufswagenartikel auf der Client-Seite zu speichern, ohne eine Sitzung oder Cookies zu verwenden. Ein Beispiel finden Sie auf smashingmagazine.com . Es ist aber auch möglich, einen staatenlosen Einkaufswagen mit Cookies zu realisieren (zumindest wenn Ihr Sortiment nicht so groß ist und 4 KB Speicherplatz für Sie ausreicht).

Verstehen Sie mich nicht falsch, das heißt nicht, dass Sie einen Einkaufswagen ohne Status zu jedem Preis implementieren sollten. Amazon oder andere große Online-Einkaufsplattformen verwenden Stateful-Shopping-Cart-Implementierungen, da für sie Benutzererfahrung und Benutzerfreundlichkeit wichtiger sind als die Anpassung an technische nicht-funktionale Anforderungen wie Skalierbarkeit.

Im Allgemeinen werden Token nicht zum Speichern von Informationen wie Einkaufswagen-Artikeln verwendet. Sie werden für eine zustandslose Authentifizierung und Autorisierung verwendet.

Und sind die wichtigsten Websites (Amazon, Google, Facebook, Twitter usw.) tatsächlich zustandslos? Verwenden sie Token oder Cookies (oder beides)?

Wenn Sie gefragt werden, ob Cookies oder Token zur Authentifizierung verwendet werden, lautet die Antwort, dass beide verwendet werden. Für Benutzer werden meist Cookies für technische Kunden, meist Token verwendet.

OK, die von Ihnen angegebene Regel ist technisch falsch. Alle Ebenen einer Webanwendung haben einen Status.

Die Intention der Regel ist "Keine sitzungsbezogenen Statusserver".

Das heißt, Sitzungsvariablen in ASP , die üblicherweise verwendet wurden, um Dinge wie Artikel im Warenkorb / Benutzernamen usw. zu erledigen.

Der Grund dafür ist, dass Ihnen der Arbeitsspeicher auf dem Server ausgeht, wenn Ihre Anwendung mehr Benutzer gewinnt. Das Verschieben des Speichers in eine Datenbank oder einen gemeinsam genutzten Cache löst das Problem nicht, da Sie immer noch einen Engpass haben.

Verschieben Sie den Status auf der Clientseite, um den Anwendungsstatus pro Benutzer beizubehalten, ohne dieses Problem zu beheben. Platzieren Sie die Warenkorbelemente beispielsweise in einem Cookie oder einem erweiterten clientseitigen Speicher.

Da die Anzahl der Clients mit der Anzahl der Benutzer skaliert, hat Ihre Anwendung insgesamt keinen Engpass und lässt sich gut skalieren.