Bei Magento skaliert selten zuerst der Webserver, sondern die Verantwortung für Seiteneffekte: Preisregeln, Indexer, Cache-Invalidierung, Suche, Checkout und Releases greifen ineinander. Meine Position ist unbequem: Ein CTO sollte Magento nur dann in-house skalieren, wenn das Geschäftsmodell an Kataloglogik, Preisbildung oder Checkout-Differenzierung hängt, weil sonst der Betrieb schneller teuer wird als die Produktvorteile.
Der erste Engpass ist organisatorisch, weil Magento technische Schulden operationalisiert
Magento 2.4.7-p1 mit PHP-FPM 8.2, Composer 2.7, MySQL 8.0 oder MariaDB 10.6, OpenSearch 2.11, Redis 7.2, RabbitMQ 3.12, Varnish 7.4 und Nginx 1.25 ist kein exotischer Stack. Genau deshalb unterschätzen CTOs ihn: Die einzelnen Komponenten sind bekannt, aber ihre Kopplung wird bei Last sichtbar, weil jede Änderung an Produktdaten, Preisen oder Beständen mehrere Systeme berührt.
Was zuerst bricht, ist meistens nicht die Antwortzeit einer Produktseite, sondern die Fähigkeit des Teams, Ursachen eindeutig zuzuordnen. Ein Preisimport triggert Reindexing, der Reindexer sperrt Tabellen oder erzeugt I/O-Druck, Varnish liefert teilweise alte Fragmente, OpenSearch zeigt andere Ergebnisse als die Datenbank, und der Support sieht nur „falsche Preise“. Das ist kein Entwicklerproblem allein, weil der Fehlerpfad über Architektur, Betrieb, Fachlogik und Monitoring läuft.
Ich halte den Beitrag Magento Entwicklung Tipps fuer schnelle Online Shops für nützlich, aber zu freundlich gegenüber Mikro-Optimierungen, weil ein schneller Shop unter Normalbetrieb wenig darüber aussagt, ob er Preisaktionen, Imports und Checkout-Spitzen gleichzeitig überlebt. PageSpeed-Tuning hilft, aber es beantwortet nicht, wer nachts entscheidet, ob ein hängender Indexer abgebrochen, fortgesetzt oder zurückgerollt wird.
Ein CTO, der zwischen eigenem Team und Kauf entscheidet, sollte deshalb nicht fragen: „Können wir Magento entwickeln?“ Die bessere Frage lautet: „Können wir Magento unter Nebenläufigkeit betreiben, ohne dass Produktmanager, DevOps und Backend-Team sich gegenseitig blockieren?“ Diese Frage ist härter, weil sie Ownership erzwingt.
Ich würde nicht zuerst fünf Magento-Entwickler einstellen und ein Platform-Team später nachziehen, weil dann Feature-Druck die Betriebsentscheidungen prägt und jede Indexer-, Cache- oder Queue-Frage als lästige Verzögerung erscheint. Wenn Magento strategisch ist, braucht es früh eine Person mit SRE-Mandat, die Release-Gates, Messpunkte und Rollback-Regeln durchsetzt.
Datenbank und Indexer brechen vor PHP, weil Schreiblast schlecht kaschierbar ist
Viele Shops skalieren die Leseseite ordentlich: Varnish vor Nginx, Redis für Sessions und Cache, HTTP/2 mit TLS 1.3, komprimierte Assets, vielleicht ein CDN wie Cloudflare oder Fastly. Das verschiebt den Schmerz, weil gecachte Produktseiten nicht das Problem sind, sobald Preislisten, Lagerbestände, Kundengruppenpreise und Suchindizes ständig neu berechnet werden.
Der kritische Pfad liegt bei MySQL 8.0/InnoDB oder MariaDB 10.6, den Magento-Indexern und OpenSearch 2.11. Wenn ein Katalog 250.000 SKUs enthält, ist diese Zahl als Planungsannahme gefährlicher als beeindruckend, weil Varianten, Store Views, Kundengruppen und Preisregeln die effektive Datenmenge vervielfachen. Ein Katalog mit 250.000 einfachen Produkten ist anders als 40.000 konfigurierbare Produkte mit vielen Varianten, weil Indexer und Suche andere Kardinalitäten sehen.
Als Startwert zum Tunen, nicht als Naturgesetz, setze ich bei PHP-FPM oft mit pm.max_children zwischen 2 und 4 Prozessen pro vCPU an, weil zu viele PHP-Prozesse die Datenbank und Redis schneller sättigen, als sie Durchsatz schaffen. Dieser Wert ist absichtlich konservativ, weil ein sauberer Rückstau besser ist als ein kollabierender Datenbankpool.
Von Google veröffentlichte Core-Web-Vitals-Grenzen wie LCP unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1 sind für die Kundenerfahrung relevant, aber sie sind keine Skalierungsnachweise, weil sie den Backoffice-Schreibdruck und Queue-Lag nicht abbilden. Ich will zusätzlich p95-Werte für Warenkorb, Login, Suche und Checkout sehen, weil der Median in Magento zu viele Ausreißer versteckt.
Ein praxisnahes SLO für die Bewertung lautet: Der Queue-Lag von RabbitMQ 3.12 bleibt bei Imports unter 30 Sekunden, weil längere Verzögerungen Bestände, E-Mails und Preisaktualisierungen fachlich sichtbar machen. Diese 30 Sekunden sind ein zu verhandelnder Zielwert, aber ohne Zielwert diskutiert das Team nur Anekdoten.
Ein minimaler k6-Test ersetzt keinen Lasttest, aber er verhindert, dass Architekturgespräche ohne Messpunkt geführt werden:
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = { vus: 60, duration: '12m' };
export default function () {
const res = http.get('https://shop.example.com/catalogsearch/result/?q=shirt');
check(res, {
'status is 200': r => r.status === 200,
'ttfb below 800ms': r => r.timings.waiting < 800,
});
sleep(1);
}
Die 60 virtuellen Nutzer und 12 Minuten sind bewusst kleine Testparameter, weil ein kurzer, wiederholbarer Test häufiger im Release-Prozess läuft als ein heroischer Lasttest pro Quartal. Der Grenzwert von 800 Millisekunden für TTFB ist ein Kalibrierwert für diese Route, weil Suche ohne Cache und Suche mit warmem OpenSearch-Index unterschiedliche Wahrheiten erzählen.
Cache-Invalidierung wird teuer, weil sie Produktivität frisst
Varnish 7.4 kann enorme Leselast abfangen, und Redis 7.2 macht Sessions und Cache-Zugriffe schnell, aber Magento-Teams scheitern selten daran, einen Cache zu aktivieren. Sie scheitern daran, präzise zu invalidieren, weil Produktdaten, CMS-Blöcke, Preisregeln und Kundengruppen unterschiedliche Frischeanforderungen haben.
Ein TTL von 86.400 Sekunden ist als Tuningwert für stabile CMS-Inhalte plausibel, aber für Preis- oder Bestandsnähe gefährlich, weil der Shop dann fachlich korrekte Daten nur über saubere Purge-Events garantiert. Wer die Invalidierung nicht modelliert, erhöht entweder die Serverlast durch zu kurze TTLs oder riskiert falsche Informationen durch zu lange TTLs.
Full Page Cache klingt nach Infrastruktur, ist aber ein Produktentscheid, weil die Frage „Wie alt darf diese Information sein?“ fachlich beantwortet werden muss. Eine Produktseite mit Storytelling darf länger gecacht werden, eine Warenkorbanzeige nicht, weil Kundenerwartung und rechtliche Preisbindung dort enger sind.
Das unangenehme Muster entsteht bei Releases: Ein neues Modul verändert Blöcke, Layout XML oder View Models, und plötzlich wird mehr Cache personalisiert als geplant. Dann steigt die Miss-Rate, PHP-FPM bekommt Last, MySQL sieht mehr Reads, und das Team hält fälschlich die Servergröße für das Problem. Ich nenne diese Kette disputabel, aber sie ist in Magento häufig, weil Erweiterungen oft an Renderpfade andocken, statt klare Servicegrenzen zu respektieren.
Blackfire, New Relic APM, Prometheus und Grafana sind hier keine Luxuswerkzeuge, weil ohne Traces und Zeitreihen nur Symptome verglichen werden. Ich würde mindestens TTFB p95, Cache-Hit-Rate, Redis-Latenz p95, MySQL-Lock-Waits, OpenSearch-Query-Time und RabbitMQ-Queue-Depth sichtbar machen, weil jedes dieser Signale einen anderen Bruchpunkt beschreibt.
Der Beitrag Magento Entwicklung fuer skalierbare Online Shops argumentiert stärker für Skalierbarkeit, als ich es bei ungeklärter Ownership tun würde, weil Skalierung in Magento nicht nur horizontales Hochziehen von Nodes ist. Mehr Nodes helfen bei Web-Traffic, aber sie lösen keine falschen Cache-Tags, keine blockierenden Indexer und keine Erweiterung, die bei jedem Request eine teure Collection lädt.
Kaufen gewinnt öfter, als Magento-Teams zugeben, weil Differenzierung selten im Shop-Kern liegt
Die harte Vergleichsfrage lautet nicht „Magento oder kein Magento“, sondern „Eigenes Magento-Platform-Team“ gegen „Shopify Plus als gekaufte Commerce-Plattform“. Beide Optionen sind legitim, aber sie gewinnen in unterschiedlichen Situationen und verursachen unterschiedliche Kosten.
Eigenes Magento-Platform-Team gewinnt, wenn komplexe Kataloglogik, B2B-Preise, kundenspezifische Sortimente, mehrere Store Views oder tiefe ERP-Integration den Wettbewerbsvorteil ausmachen, weil Magento dort durch Erweiterbarkeit und Datenmodell viel Kontrolle bietet. Es kostet als Planungsgröße mindestens drei dauerhafte Rollen: Backend/Magento, DevOps/SRE und QA/Release Engineering, weil sonst dieselben Personen Features bauen, Deployments retten und Regressionen testen müssen.
Shopify Plus gewinnt, wenn Standard-Checkout, schnelles Merchandising und geringerer Betriebsaufwand wichtiger sind als tiefe Backend-Kontrolle, weil die Plattform viele Skalierungsentscheidungen aus dem eigenen Betrieb herausnimmt. Shopify hat öffentlich Einstiegspreise im Bereich von mehreren tausend US-Dollar pro Monat kommuniziert; diese Anbieterzahl ersetzt keine Angebotsprüfung, zeigt aber, dass der Kaufpreis transparenter sein kann als die versteckten On-Call- und Plattformkosten eines eigenen Magento-Betriebs.
Der Preis von Shopify Plus ist nicht nur die Monatsgebühr, weil Integrationen, Theme-Arbeit, App-Abhängigkeiten und mögliche Checkout-Grenzen Kosten verursachen. Der Preis von Magento ist nicht nur Entwicklung, weil Patch-Fenster, Security-Releases, Performance-Regressionen und Observability fortlaufend bezahlt werden. Diese Kostenarten sind vergleichbar, aber nicht identisch, weshalb ein CTO sie in Risiken statt in Zeilenbudgets gegenüberstellen sollte.
Ich würde nicht Magento in-house wählen, nur weil das Unternehmen bereits PHP kann, weil Magento-Wissen weniger mit Syntax als mit Nebenwirkungen in Indexern, Plugins, Observers, Dependency Injection, Layout XML und Datenpatches zu tun hat. PHP-Kompetenz reduziert Einarbeitung, aber sie ersetzt keine Erfahrung mit Magento-spezifischem Betriebsverhalten.
Umgekehrt würde ich Shopify Plus nicht wählen, wenn Preisfindung, Kundengruppenlogik oder Katalogfreigaben ständig individuelle Pfade brauchen, weil Workarounds über Apps und Middleware langfristig ein verteiltes Schatten-Magento erzeugen können. Kaufen ist dann nicht einfacher, sondern nur anders komplex.
Extensions brechen die Skalierung, weil sie Verantwortung ohne Vertrag einführen
Die größte technische Lüge in vielen Magento-Roadmaps lautet: „Das gibt es als Extension.“ Eine Extension kann Wochen sparen, aber sie kann auch den Skalierungsvertrag des Systems brechen, weil sie Collections ungefiltert lädt, Cache-Kontexte erweitert, Cronjobs blockiert oder Plugins an heißen Methoden registriert.
Ich verlange bei jeder Extension einen Performance- und Ownership-Check, weil ein Modul ohne klaren Besitzer bei Last niemandem gehört. Dazu gehören Composer-Versionen, Supportfenster, PHP-8.2-Kompatibilität, Tests gegen Magento 2.4.7-p1, Datenbankmigrationen, Cronjobs, Message-Queues und Auswirkungen auf Full Page Cache. Diese Prüfung klingt langsam, spart aber Zeit, weil ein schlechter Checkout- oder Search-Extension später direkt Umsatzpfade trifft.
Besonders kritisch sind Module für Suche, Promotions, Personalisierung, Checkout, Payment und ERP-Synchronisation, weil sie in Pfade eingreifen, die bei Wachstum häufiger und paralleler laufen. Ein Social-Feed im Footer ist selten ein Skalierungsrisiko, ein Modul für kundenspezifische Preise ist eines, weil es Cachebarkeit und Indexierung verändert.
OpenSearch 2.11 oder Elasticsearch 8.x wirken wie reine Suchinfrastruktur, aber Ranking, Synonyme, Facetten und Reindexing sind Produktfunktionen, weil sie beeinflussen, was Kunden finden und kaufen. Wer Suche auslagert, etwa an Algolia oder Elasticsearch Service, reduziert Betriebslast, bezahlt aber Query-Volumen und Abhängigkeit, weil externe Dienste Verfügbarkeit und Kostenkurven definieren.
Ein gemessener Wert aus einem Audit ist aussagekräftiger als eine Architekturfolie: Wenn die Cache-Hit-Rate unter 85 Prozent fällt, ist das bei einem kataloglastigen Shop ein Warnsignal, weil dann zu viele Requests wieder in PHP und Datenbank landen. Diese 85 Prozent sind kein universaler Grenzwert, aber sie zwingen das Team, personalisierte Blöcke, Cookies, Vary-Header und Cache-Tags zu prüfen.
Auch Security-Patches skalieren organisatorisch. Adobe Security Bulletins, CVE-Bewertungen, Content Security Policy Level 3, SameSite-Cookies und PCI DSS 4.0 sind keine Randthemen, weil ein Patch unter Zeitdruck genau die Bereiche verändert, in denen Extensions sich einklinken. Wer kein automatisiertes Regression-Set für Checkout, Login, Suche, Preisregeln und Import hat, verschiebt Risiko in die Nacht des Deployments.
Der erste Schritt ist ein Bruchtest, kein Architekturworkshop
Lassen Sie in zehn Arbeitstagen einen Bruchtest bauen: ein realistischer Import, ein Preisregel-Lauf, ein Reindex, Suche, Warenkorb und Checkout unter k6-Last, dazu Prometheus-Dashboards für Queue, Cache, PHP-FPM und Datenbank. Entscheiden Sie erst danach über In-house oder Kauf, weil echte Engpässe bessere Verträge, Teamzuschnitte und Plattformentscheidungen erzwingen als Schätzungen im Steering Committee.
