Ausgangslage
Eine Maschine kann viel ausliefern. Sie soll aber nicht alles wissen.
Die Shopware-Storefront lief neben PHP-FPM, Hintergrundarbeit und einem umfangreichen Plugin- und Katalogprofil. Datenbank, Suche und Caching waren relevante Teile des Betriebs. Für steigende Last war ein zweiter Webnode denkbar – aber nur, wenn die zustandsbehafteten Teile vorher sauber ausgelagert werden.
Architekturentscheidung
Aus einem Shopware-Monolithen wird ein klar verteilter Betrieb.
Die Webschicht wird austauschbar. Redis übernimmt den gemeinsamen flüchtigen Zustand: Sessions, Cart-/Context-Nähe, Cache und Locks. Die SQL-Datenbank bleibt führend für Bestellungen und Bestände. OpenSearch bearbeitet Suche. Queue-Worker und geplante Aufgaben bekommen klare Zuständigkeiten statt um dieselben Ressourcen wie der Checkout zu konkurrieren.
Der Gegenbeweis
Ein Cache kann die Antwortzeit drücken – und trotzdem der falsche Fix sein.
Ein Test mit HTML-Cache zeigte, wie schnell anonyme Storefront-Seiten werden können. Der Test wurde nicht als Erfolg verkauft, als sich die Warenkorb-Semantik nicht mehr belastbar verhielt. Das war die richtige Entscheidung: Ein Commerce-System ist nicht schneller, wenn der Checkout schneller falsch wird.
Die Konsequenz war, Performance nicht mehr als isolierte Seitenmetrik zu behandeln. Storefront, eingeloggter Zustand, Cart, Checkout und Hintergrundarbeit wurden als unterschiedliche Pfade gedacht und geprüft.
Lastspitzen
Der zweite Node ist der letzte Schritt, nicht der erste.
- Sessions dürfen bei einem Node-Wechsel nicht verschwinden.
- Locks müssen für alle PHP-Prozesse gelten, sonst entstehen Doppelarbeit und Race Conditions.
- Medien, Konfiguration und Secrets müssen auf jedem Webnode kontrolliert identisch sein.
- Worker und Cron laufen nur dort, wo sie bewusst eingeplant sind – nicht doppelt auf jedem Webserver.
- Load Tests prüfen Cart und Checkout, nicht nur eine schnelle Startseite.
Ergebnis
Eine Architektur, die Lastspitzen kontrolliert abfängt.
Die entscheidende Leistung war kein einzelner Redis-Schalter und kein Cache-Trick. Es war die klare Trennung von Web-Auslieferung, gemeinsamem Zustand, führenden Daten, Suche und Hintergrundarbeit. Damit kann der Betrieb Webkapazität ergänzen, ohne Warenkorb und Checkout zum Experiment zu machen.
Genau diese Reihenfolge prüfen wir auch bei anderen Shopware-Shops: erst Pfade und Zustand verstehen, dann Last verteilen.