Eventual Consistency im Composable-Storefront: Wann sie ein Feature ist, wann ein Bug

Kelly Goetsch nennt Eventual Consistency in Microservices for Modern Commerce (O'Reilly, 2016) eines der härtesten Konzepte der Microservices-Architektur. Er schreibt: "One of the biggest issues that enterprises have with microservices is the fact that not all data is strongly consistent."

Das war 2016 eine ehrliche Warnung. 2026 ist sie zum häufigsten Stolperstein in Composable-Projekten geworden, nicht weil Eventual Consistency falsch ist, sondern weil die meisten Teams keine klare Taxonomie haben, welche Daten welche Konsistenz-Garantie brauchen.

Die Folge: Entweder zu viel Strong Consistency (Performance-Probleme, Latenz, Verfügbarkeitsrisiken), oder zu wenig (Checkout-Fehler, veraltete Preise im Warenkorb, falsche Lagerbestandsanzeigen). Beides ist teuer. Beides ist vermeidbar.

Was Eventual Consistency bedeutet, präzise

In einem Monolith gibt es einen einzigen Datenspeicher. Wenn die Promotions-Engine einen Preis ändert, sieht jede Anfrage sofort den neuen Preis. Das ist Strong Consistency: jede Leseoperation liefert den aktuellen Wert, immer.

In einer Microservices-Architektur gibt es per Definition mehrere Datenspeicher. Der Pricing-Microservice hält den aktuellen Preis. Der Product-Catalog-Microservice hält eine gecachte Kopie. Die Search-Microservice hält eine weitere Kopie. Wenn der Pricing-Microservice einen neuen Preis schreibt, verbreitet sich diese Information über Events, asynchron.

Eventual Consistency bedeutet: Die gecachten Kopien werden irgendwann aktualisiert. Nicht sofort. Die Zeitspanne kann Millisekunden sein, Sekunden, oder, bei Systemstress, Minuten.

Goetsch illustriert das am Beispiel von ATMs: "Most ATMs will still dispense money if they lose connectivity back to the centralised bank. Banks favour availability over consistency for business reasons, an ATM that's available makes money." Das ist die bewusste Entscheidung für Eventual Consistency aus Verfügbarkeitsgründen.

Die Frage ist nicht: Eventual Consistency ja oder nein? Die Frage ist: Für welche Daten ist das akzeptabel?

Drei Kategorien von Daten im Composable-Storefront

Eine nützliche Taxonomie, die in der Praxis funktioniert:

Kategorie 1: Kann eventual consistent sein

Diese Daten ändern sich selten, haben keinen direkten Transaktion-Impact, und kleine Inkonsistenzen haben keine messbaren Business-Konsequenzen:

• Produktbeschreibungen und Rich-Content: Text, Bilder, Attribute. Wenn eine Produktbeschreibung für zehn Minuten eine veraltete Version zeigt, ist das tolerierbar. Kein Checkout-Impact.
• Kategorie-Struktur und Navigation: Neue Kategorien, geänderte Navigations-Hierarchien. Der Rollout kann über Minuten verteilt sein.
• Statische Marketing-Content-Elemente: Blog-Posts, Landing-Page-Copy, Editorial-Content.
• Produkt-Empfehlungen (Trending, Related): Empfehlungs-Algorithmen arbeiten ohnehin mit historischen Daten, ein Lag von Minuten ist semantisch irrelevant.
• Bewertungen und Reviews: Neue Reviews erscheinen mit einem Delay von Minuten, absolut akzeptabel.

Für diese Daten empfehlen sich aggressive Cache-TTLs (Stunden bis Tage), CDN-Caching an der Edge und Event-basierte Cache-Invalidierung, wenn sich Daten ändern.

Kategorie 2: Muss strong consistent sein

Diese Daten haben direkten Checkout-Impact. Inkonsistenz hier verursacht echte Business-Schäden: fehlerhafte Bestellungen, überverkaufte Produkte, falsche Abrechnungen.

• Lagerbestand im Checkout: Goetsch beschreibt das explizit: "The shopping cart microservice should probably query the inventory microservice to ensure that there's inventory available for each product in the shopping cart. It would be a terrible experience if a customer made it to the final stage of checkout before being told a product was unavailable." Das ist die Ausnahme von der Eventual-Consistency-Regel.
• Preise im aktiven Warenkorb: Wenn ein Preis sich ändert, während ein Nutzer im Checkout ist, muss der Warenkorb aktualisiert werden.
• Promotions-Anwendung im Checkout: Ob ein Promo-Code gültig ist, muss der Promotions-Microservice in Echtzeit bestätigen, nicht der Catalog-Cache.
• Payment-Status: Zahlungsbestätigungen und -fehler sind per Definition strong-consistency-pflichtig.

Für diese Daten gilt: direkte Calls zum System-of-Record-Microservice, kein Cache. Das kostet Latenz, aber der Business-Schaden durch falsche Daten ist höher als der Latenz-Cost.

Kategorie 3: Grauzone, kontextabhängig

Diese Daten haben Transaktion-Relevanz, aber der Konsistenz-Bedarf hängt vom Kontext ab:

• Preise auf Produkt-Listing-Seiten: Für Browse-Kontext ist ein leichter Lag akzeptabel. Im Checkout nicht.
• Lagerbestand-Anzeige (in stock / out of stock) auf PDP: Eine kurze Inkonsistenz ist tolerierbar, solange im Checkout frisch geprüft wird. Aber "Jetzt kaufen"-Calls-to-Action mit veraltetem Lagerbestand produzieren Frustration.
• Personalisierte Preise nach Segment-Wechsel: Wenn ein Nutzer von einem Preis-Segment in ein anderes wechselt (z.B. durch einen Loyalty-Status-Upgrade), wie lange darf der alte Preis noch gecacht werden?
• Flash-Sale-Preise: In den ersten Sekunden eines Flash-Sale können gecachte Preise massive Divergenzen erzeugen.

Für Grauzone-Daten empfiehlt sich ein expliziter TTL per Kontext: kürzere TTLs für Checkout-nahe Views, längere TTLs für Browse-Kontext.

Das System-of-Record-Pattern

Goetsch beschreibt das Grundmuster für Eventual Consistency klar: "There is always at least one microservice that has the most up-to-date data." Jeder Microservice ist System of Record für seinen Datenbereich. Andere Microservices halten gecachte Read-Models.

Für einen Composable-Storefront bedeutet das konkret:

`` System of Record: Pricing-Microservice (commercetools Pricing API) Cached Read-Model: Product Catalog (mit denormalisiertem Preis) Read-Model-Update: via Pricing-Changed-Event Checkout-Read: direkt gegen Pricing-Microservice (bypasses cache) ``

Das ist das Pattern, das Goetsch mit seinem Kategorie-Seiten-Beispiel beschreibt: Der Product-Catalog-Microservice aggregiert Daten aus Pricing, Inventory und Promotions in einem Read-Model, das für Browse-Anfragen optimiert ist. Im Checkout fragt der Shopping-Cart-Microservice direkt beim Inventory-Microservice an, nicht beim Catalog.

Frontend-Implikation: Caching-Policies deklarativ machen

Die meisten Composable-Stacks implementieren Caching-Policies heute verteilt: Im Next.js-Page-Component, im API-Route-Handler, in einer Edge-Middleware, im CDN-Konfigurationsfile. Kein einziger Entwickler hat einen vollständigen Überblick über alle Caching-Regeln im System.

Das ist das Eventual-Consistency-Äquivalent des Monolith-Problems: dezentralisierte, implizite Regeln erzeugen Inkonsistenz-Bugs, die schwer zu debuggen sind.

Die bessere Lösung: Caching-Policies deklarativ pro Datentyp definieren, an einer Stelle, die für alle Layers sichtbar ist. Im Laioutr Studio lässt sich genau das konfigurieren, welche Datenquelle welche TTL bekommt, für welchen Seiten-Kontext, mit welcher Cache-Invalidierungs-Logik. Das ist nicht nur ein technisches Feature, es ist die notwendige Governance-Schicht für Eventual Consistency in einem Multi-Team-Setup.

Typische Fehler in der Praxis

Fehler 1: Inventory-Status auf PDPs aggressiv cachen Wenn "auf Lager" für zwei Stunden gecacht ist und das Produkt ausverkauft wird, rufen Nutzer direkt in den Checkout-Fehler. Besser: Lagerbestand-Anzeige mit kurzem TTL (wenige Minuten) oder Soft-State-Indikatoren ("In der Regel auf Lager") für unvermeidlich gecachte Werte.

Fehler 2: Promotions-Prüfung im Catalog-Cache statt am System of Record Wenn ein Promo-Code im Catalog-Cache als gültig erscheint, aber der Promotions-Microservice ihn bereits deaktiviert hat, entstehen Checkout-Fehler oder illegitim angewendete Rabatte. Promotions-Validierung gehört immer zum System of Record.

Fehler 3: Kein explizites Cache-Busting bei Price-Change-Events Wenn ein neuer Preis im Pricing-Microservice gesetzt wird, sollte ein Event den Catalog-Cache aktiv invalidieren, nicht passiv auf den TTL-Ablauf warten. Event-getriebene Cache-Invalidierung ist die Lösung, die Strong Consistency vermeidet und trotzdem kurze Inkonsistenz-Windows hält.

Fehler 4: Strong Consistency für alle Daten fordern Das andere Extrem: aus Angst vor Inkonsistenz alle Daten synchron aus System-of-Record-Microservices lesen. Das produziert eine N+1-Abfrageproblem auf Seiten-Ebene (eine Kategorie-Seite mit 20 Produkten = 20+ synchrone Calls). Goetsch warnt explizit: "There are very few instances for which data must be truly consistent. Think very hard about introducing this as a requirement, because the consequences (coupling, performance, availability) are so damaging."

Fazit: Eventual Consistency braucht eine bewusste Taxonomie

Eventual Consistency ist kein Bug in Composable-Architekturen. Sie ist ein Design-Entscheid, der explizit getroffen werden muss, pro Datentyp, pro Kontext.

Das eBook von Goetsch hat das Konzept 2016 klar beschrieben. Was es nicht beschreibt (weil es nicht sein Fokus war): Wie trifft ein Frontend-Team diese Entscheidungen systematisch, und wer hält die Übersicht?

Die Antwort 2026: deklarative Caching-Policies in einer Frontend-Management-Platform, die für alle Teams sichtbar und editierbar sind, statt verteilter Middleware-Magic, die niemand vollständig versteht.

Mehr zur technischen Umsetzung von BFF-Patterns, die Agents und UIs gleichermaßen bedienen, findest du in Vom API-Gateway zum AI-Agent-Layer.

[Demo: Deklaratives Caching im Laioutr Studio ansehen](https://www.laioutr.com/demo)

Quelle: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.