Shopware Minden: Technischer Leitfaden für E-Commerce-Profis

Du planst ein Shopware-6-Projekt oder optimierst einen bestehenden Shop? Dieser Artikel liefert dir technische Tiefe zu Hosting-Topologien, Caching-Strategien, Integrationsarchitekturen, Performance-Optimierung und Betriebsmodellen – mit konkreten Shopware-6-Spezifika, die über Standard-Best-Practices hinausgehen. Ziel ist, dir belastbare Entscheidungsleitplanken zu geben, damit du Architektur, Infrastruktur und Prozesse präzise planen kannst – bei Bedarf auch gemeinsam mit einer Shopware Agentur.

Für wen dieser Artikel gedacht ist

Du hast bereits E-Commerce-Erfahrung, kennst die Grundlagen von Shopware 6 und suchst jetzt nach technischen Details für Hosting-Setup, Caching-Invalidierung, Integrationsmuster, Plugin-Governance, Release-Strategien und Monitoring. Du brauchst keine Einführung in grundlegende E-Commerce-Konzepte, sondern konkrete Architektur-Entscheidungen, Performance-Messpunkte und Umsetzungsbeispiele.

Was du nach diesem Artikel weißt

• Hosting-Topologien und deren Trade-offs (Single-Server, Load-Balanced, Kubernetes-basiert)
• HTTP-Cache-Invalidierung und Caching-Layer in Shopware 6
• Elasticsearch-/OpenSearch-Konfiguration für Performance und Relevanz
• Plugin-Governance-Kriterien und Update-/Release-Strategien (Staging, Blue-Green, Canary)
• Integrationsmuster mit konkreten Sync-Frequenzen, Daten-Mastering-Matrix und typischen Fehlerbildern
• Monitoring-Stack und Performance-Messpunkte (Core Web Vitals, Backend-Metriken, Infrastruktur)

Hosting-Topologien: Architektur-Entscheidungen und Trade-offs

Die Wahl deiner Hosting-Topologie bestimmt Skalierbarkeit, Ausfallsicherheit und Performance. Hier die gängigen Setups mit ihren Vor- und Nachteilen.

Single-Server-Setup

Alle Komponenten (Web, Datenbank, Redis, Elasticsearch) laufen auf einem Server. Geeignet für kleine Shops (unter 10.000 Produkte, unter 500 Bestellungen pro Monat).

Infrastruktur-Komponenten:

• Webserver: Nginx oder Apache mit PHP-FPM (PHP 8.1 oder höher, OpCache aktiviert)
• Datenbank: MySQL 8.0 oder höher bzw. MariaDB 10.5 oder höher (InnoDB, innodb_buffer_pool_size mindestens 1 GB)
• Cache: Redis 6 oder höher für Session-Storage und Object-Cache
• Queue: Symfony Messenger mit Redis-Transport oder Doctrine-Transport
• Elasticsearch: Optional lokal (nicht empfohlen unter 4 GB RAM)

Empfohlene Server-Specs (Minimum):

• 4 vCPUs, 8 GB RAM, 80 GB SSD (NVMe bevorzugt)
• PHP-FPM: pm.max_children=50, pm.start_servers=10, pm.min_spare_servers=5, pm.max_spare_servers=15
• OpCache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 (Production)

Load-Balanced Multi-Server-Setup

Web-Layer horizontal skaliert (mehrere Application-Server hinter Load-Balancer), dedizierte Server für Datenbank, Redis, Elasticsearch. Geeignet für mittlere bis große Shops (ab 500 Bestellungen pro Monat, hoher Traffic).

Infrastruktur-Komponenten:

• Load-Balancer: HAProxy, Nginx, AWS ALB, Cloudflare Load Balancing
• Application-Server: 2 oder mehr identische Web-Server (Auto-Scaling möglich)
• Datenbank: Dedizierter MySQL-Server (Master-Slave-Replikation für Read-Skalierung)
• Redis: Dedizierter Redis-Server (Sentinel für HA oder Redis Cluster ab 3 Nodes)
• Elasticsearch: Dedizierter Node (mindestens 3-Node-Cluster für Production empfohlen)
• Message-Queue-Worker: Dedizierte Worker-Server oder Container (Symfony Messenger Consumer)

Wichtig für Session-Handling: Shopware 6 nutzt standardmäßig PHP-Sessions. Bei Load-Balancing MUSS Redis als Session-Handler konfiguriert werden (framework.session.handler_id: Redis-SessionHandler in config/packages/framework.yaml). Alternativ: Sticky-Sessions auf Load-Balancer-Ebene (nicht empfohlen, da Single Point of Failure pro Session).

Kubernetes-basiertes Setup

Shopware 6 läuft in Container-Orchestrierung (Kubernetes, Docker Swarm). Geeignet für große Shops, Multi-Tenant-Setups, hohe Skalierungsanforderungen.

Infrastruktur-Komponenten:

• Container-Images: Shopware-6-Docker-Images (offizielles shopware/development oder Custom-Builds)
• Ingress-Controller: Nginx Ingress, Traefik (SSL-Terminierung, Routing)
• Persistent-Volumes: Für Medien (empfohlen: S3-kompatibles Object-Storage statt PV)
• ConfigMaps/Secrets: Für Umgebungsvariablen (DB-Credentials, Redis-Hosts, API-Keys)
• StatefulSets: Für Datenbank, Redis, Elasticsearch (wenn selbst gehostet)
• Deployments: Für Shopware-Web-Pods (Replicas: mindestens 2, HPA für Auto-Scaling)

Shopware-6-spezifische Container-Konfiguration:

• APP_ENV=prod, APP_DEBUG=0 (niemals Debug-Mode in Production)
• DATABASE_URL, REDIS_URL, ELASTICSEARCH_URL per Secret injizieren
• Medien-Storage: S3-Plugin nutzen (shopware/s3) statt lokalem Dateisystem (PV-Probleme bei Pod-Restart)
• HTTP-Cache: Varnish als Sidecar-Container oder dedizierter Service (empfohlen bei hohem Traffic)

Hosting-Entscheidungsmatrix

HTTP-Cache und Caching-Layer: Invalidierung und Performance

Shopware 6 bietet mehrere Caching-Layer. Deren Konfiguration entscheidet über Ladezeiten und Cache-Kohärenz.

Caching-Layer im Überblick

HTTP-Cache-Konfiguration

Shopware 6 nutzt standardmäßig Symfony HttpCache (Reverse-Proxy in PHP). Für Production empfohlen: Varnish (deutlich performanter) – Details zur passenden Setup-Variante findest du auch im Beitrag zu Shopware 6 mit Varnish.

Symfony HttpCache aktivieren:

• In .env: SHOPWARE_HTTP_CACHE_ENABLED=1
• Routing: Requests laufen durch public/index.php, HttpCache-Layer prüft Cache, bei Miss: Shopware generiert Response, speichert in Cache
• Cache-Storage: Standardmäßig Dateisystem (var/cache/prod/http_cache), besser: Redis (shopware.http_cache.redis_url konfigurieren)

Varnish konfigurieren:

• Varnish VCL für Shopware 6 nutzen (offizielle VCL: vendor/shopware/core/Framework/Resources/config/varnish.vcl)
• Varnish vor Application-Server schalten (Port 80/443 zu Varnish, Port 8000 Application)
• Cache-Invalidierung: Shopware sendet PURGE-Requests mit Cache-Tags an Varnish
• Health-Check: Varnish prüft Backend-Verfügbarkeit (backend probe in VCL)

Cache-Tags und Invalidierung:

Shopware 6 sendet bei jeder Response HTTP-Header mit Cache-Tags (z. B. product-abc123, category-xyz). Wenn ein Produkt geändert wird, sendet Shopware PURGE-Request mit diesem Tag an HTTP-Cache, Cache invalidiert nur betroffene Seiten (nicht gesamten Cache).

Typische Cache-Tags:

• product-{productId}
• category-{categoryId}
• navigation-{salesChannelId}
• footer-{salesChannelId}
• cms-{cmsPageId}

Invalidierungs-Trigger:

• Produkt-Update (Preis, Name, Verfügbarkeit) invalidiert product-Tag
• Kategorie-Update invalidiert category-Tag
• CMS-Änderung invalidiert cms-Tag
• Theme-Änderung invalidiert gesamten Cache (theme:compile triggert Cache-Clear)

Fehlerbilder und Lösungen:

• Problem: Cache zeigt veraltete Preise nach ERP-Sync. Ursache: Preis-Update triggert keine Cache-Invalidierung (Bug oder Custom-Import umgeht Events). Lösung: Stelle sicher, dass Produkt-Updates über Shopware DAL laufen (ProductRepository update()), nicht direkt per SQL. Alternativ: Manuell Cache-Invalidierung triggern (CacheInvalidator-Service nutzen).
• Problem: Cache-Invalidierung funktioniert nicht bei Varnish. Ursache: Varnish-Host falsch konfiguriert oder Firewall blockiert PURGE. Lösung: Prüfe SHOPWARE_HTTP_CACHE_INVALIDATION_HOSTS in .env. Teste PURGE manuell.

Object-Cache (Redis)

Redis cacht Doctrine-Entities, Konfigurationen, Übersetzungen. Konfiguration in config/packages/framework.yaml:

• cache.adapter.redis: dsn: redis://localhost (oder Redis-Cluster-URL)
• Shopware nutzt automatisch Redis für app.cache, system.cache

Redis-Tuning:

• maxmemory-policy: allkeys-lru (Least Recently Used eviction)
• maxmemory: 2gb (anpassen je nach Katalog-Größe)
• Redis-Persistence: RDB-Snapshots für Wiederherstellung (save 900 1, save 300 10)

Typische Fehlerbilder:

• Problem: Redis läuft voll (maxmemory erreicht), Cache-Writes schlagen fehl. Lösung: Erhöhe maxmemory oder prüfe, ob alte Keys nicht korrekt ablaufen (TTL setzen).
• Problem: Nach Deployment zeigt Shop alte Daten. Lösung: Cache-Clear nach Deployment (bin/console cache:clear, triggert auch Redis-Flush) – je nach Setup helfen zusätzlich klare Prozesse rund um Shopware Cache leeren.

Elasticsearch/OpenSearch: Konfiguration für Performance und Relevanz

Für Shops mit mehr als 5.000 Produkten oder komplexer Filterlogik ist Elasticsearch/OpenSearch Pflicht. MySQL-Volltextsuche skaliert nicht und liefert schlechte Relevanz.

Elasticsearch vs. OpenSearch

Empfehlung: OpenSearch für neue Projekte (Open-Source, günstiger bei AWS). Elasticsearch wenn bereits Infrastruktur vorhanden.

Elasticsearch-Setup für Shopware 6

Minimum-Konfiguration (Single-Node für Entwicklung/Test):

• Elasticsearch 7.x oder 8.x (8.x erfordert Shopware 6.5 oder höher)
• Heap-Size: Mindestens 1 GB (ES_JAVA_OPTS="-Xms1g -Xmx1g")
• Index-Settings: 1 Shard, 0 Replicas (für Single-Node)

Production-Konfiguration (3-Node-Cluster):

• 3 Master-fähige Nodes (quorum für Split-Brain-Vermeidung)
• Heap-Size: 50 % des RAM, max. 32 GB (z. B. bei 64 GB RAM: -Xms31g -Xmx31g)
• Index-Settings: 3 Shards, 1 Replica (für Ausfallsicherheit)
• SSD-Storage (NVMe bevorzugt, I/O-kritisch)

Shopware-6-Konfiguration:

• In .env: OPENSEARCH_URL=http://localhost:9200 (oder Cluster-Endpoint)
• Index erstellen: bin/console es:index:create
• Daten indexieren: bin/console es:index (initial), danach automatisch bei Entity-Updates
• Index-Alias: Shopware nutzt Alias-Mechanismus (z. B. sw_product_de, sw_product_en) für Zero-Downtime-Reindexing

Performance-Tuning

Relevanz-Optimierung:

• Boosting: Wichtige Felder höher gewichten (z. B. Produktname Boost 3, Beschreibung Boost 1). In Shopware 6: Custom Scoring per Plugin (ElasticsearchProductSearchBuilder erweitern).
• Synonyme: Definiere Synonym-Filter (z. B. Laptop = Notebook). In Shopware: Custom Analyzer in Index-Settings (elasticsearch.index_settings in config).
• Fuzzy-Search: Aktiviere Fuzziness für Tippfehler-Toleranz (Shopware Standard: Fuzziness AUTO).

Filter-Performance:

• Aggregationen cachen: Elasticsearch cacht Aggregations-Results automatisch (Node Query Cache).
• Häufige Filter zuerst: Filter-Reihenfolge beeinflusst Performance (z. B. Verfügbarkeit vor Farbe, wenn weniger Treffer).

Index-Tuning:

• Refresh-Interval erhöhen: Standard 1s, für Bulk-Indexing auf 30s oder -1 setzen (nach Import: manuell refresh triggern).
• Mapping optimieren: Nur Felder indexieren, die durchsucht/gefiltert werden. In Shopware: Custom-Fields nur indexieren wenn nötig (Definition in Entity-Extension).

Typische Fehlerbilder und Lösungen

• Problem: Suche liefert keine Ergebnisse nach Produktimport. Ursache: Index nicht aktualisiert. Lösung: bin/console es:index (oder prüfe, ob Message-Queue-Worker läuft – Indexierung läuft asynchron).
• Problem: Suche sehr langsam (über 2 Sekunden). Ursache: Zu viele Shards, schlechte Query-Struktur oder zu wenig Heap. Lösung: Reduziere Shards (z. B. von 5 auf 3), erhöhe Heap, prüfe Query-Profiling (Elasticsearch Profiler nutzen).
• Problem: Elasticsearch-Cluster gelb/rot. Ursache: Replicas können nicht zugewiesen werden (zu wenig Nodes) oder Disk-Space voll. Lösung: Füge Nodes hinzu oder setze Replicas auf 0 (nicht empfohlen für Production).

Plugin-Governance: Qualitätskriterien und Update-Strategie

Plugins erweitern Shopware, können aber auch Risiken bergen: Performance-Probleme, Security-Lücken, Update-Konflikte. Eine klare Plugin-Governance ist essentiell.

Plugin-Qualitätskriterien

Plugin-Governance-Prozess

• Vor Installation: Plugin gegen Kriterien prüfen, Testinstallation auf Staging, Performance-Profiling, Code-Review bei Custom-Plugins
• Freigabe: Nur durch Tech-Lead oder definierten Approval-Prozess
• Dokumentation: Welches Plugin, warum installiert, welche Konfiguration, wer verantwortlich (z. B. in Confluence oder README)
• Update-Zyklus: Monatlich oder quartalsweise Plugin-Updates prüfen und einspielen (nie automatisch ohne Test)
• Deprecation: Plugins regelmäßig auf Notwendigkeit prüfen – nicht genutzte Plugins deinstallieren

Typische Plugin-Fehlerbilder

• Problem: Nach Plugin-Update ist Checkout kaputt. Ursache: Plugin überschreibt Core-Service oder Template inkorrekt. Lösung: Plugin deaktivieren, Rollback, Issue an Entwickler melden. Langfristig: Auf Alternativen prüfen oder Custom-Fix.
• Problem: Shop sehr langsam nach Plugin-Installation. Ursache: Plugin fügt N+1-Queries hinzu oder lädt zu viele Daten. Lösung: Profiling (Symfony Profiler, Blackfire), Plugin-Code optimieren oder Alternative suchen.
• Problem: Plugin-Konflikte (Plugin A und Plugin B überschreiben denselben Service). Lösung: Service-Decoration-Priorität anpassen (in services.xml: decoration_priority="100") oder eines der Plugins entfernen.

Release- und Update-Strategie: Staging, Blue-Green, Canary

Ein klarer Release-Prozess minimiert Ausfallzeiten und Rollback-Risiken. Hier gängige Strategien mit Shopware-6-Spezifika.

Staging-Umgebung (Minimum)

Jedes Shopware-6-Projekt braucht mindestens eine Staging-Umgebung (Klon der Production, identische Infrastruktur, anonymisierte Produktionsdaten).

• Zweck: Testen von Updates, Plugins, Theme-Änderungen vor Production-Deployment
• Deployment-Flow: Code-Change zu Staging-Deploy zu QA-Test zu Production-Deploy
• Daten-Sync: Regelmäßig Production-DB-Dump nach Staging (anonymisiert: Kunden, Bestellungen)
• Tooling: Deployer, Capistrano, Ansible oder CI/CD-Pipeline (GitLab CI, GitHub Actions, Bitbucket Pipelines)

Blue-Green-Deployment

Zwei identische Production-Umgebungen (Blue = aktiv, Green = Standby). Deployment auf Green, Test, dann Traffic-Switch.

• Vorteil: Zero-Downtime, sofortiger Rollback möglich (Traffic zurück auf Blue)
• Nachteil: Doppelte Infrastruktur-Kosten, DB-Migration-Probleme bei Breaking-Changes
• Umsetzung: Load-Balancer oder DNS-Switch (Blue/Green jeweils eigene URL, Load-Balancer routet Traffic)

Shopware-6-Spezifika:

• DB-Migrationen auf Green laufen lassen (bin/console database:migrate), danach Anwendung deployen
• Falls Migration Breaking-Change: Maintenance-Mode aktivieren (bin/console sales-channel:maintenance:enable) – praxisnahe Hinweise dazu liefert auch der Beitrag zum Shopware Maintenance Mode.
• Nach Traffic-Switch: Blue-Umgebung als Standby behalten (für Rollback)

Canary-Deployment

Neues Release wird nur für einen kleinen Prozentsatz der User ausgerollt (z. B. 5 %), Rest bekommt alte Version. Monitoring: Fehlerrate, Performance. Bei OK: schrittweise auf 100 %.

• Vorteil: Risikominimierung, echte User-Tests in Production
• Nachteil: Komplexere Infrastruktur (Feature-Flags oder Traffic-Routing nötig)
• Umsetzung: Feature-Flags (LaunchDarkly, Unleash) oder Load-Balancer-Routing (z. B. 95 % auf Old-Pods, 5 % auf New-Pods)

Update-Strategie für Shopware 6

Shopware-Updates (Minor/Patch) sollten regelmäßig eingespielt werden (Security, Performance, Bugfixes).

• Patch-Updates (6.5.1 zu 6.5.2): Monatlich, geringe Breaking-Changes, schnell einspielen
• Minor-Updates (6.5 zu 6.6): Quartalsweise, können Breaking-Changes enthalten, ausführlicher Test nötig
• Major-Updates (6.x zu 7.x): Selten, große Breaking-Changes, Projekt-Level-Aufwand (Wochen bis Monate)

Update-Prozess:

• Changelog lesen
• Lokale Test-Umgebung: composer update shopware/core shopware/storefront shopware/administration (mit Version-Constraint)
• Migrations laufen lassen: bin/console database:migrate --all
• Plugins-Kompatibilität prüfen (manche Plugins sind nicht sofort kompatibel)
• Regressions-Tests (automatisiert: PHPUnit, Cypress; manuell: Checkout, Produktsuche, Admin)
• Staging-Deployment, QA-Tests
• Production-Deployment (Wartungsfenster oder Blue-Green)

Typische Update-Fehlerbilder

• Problem: Nach Shopware-Update ist Admin-Login kaputt. Ursache: Cache nicht geleert oder Assets nicht neu kompiliert. Lösung: bin/console cache:clear, bin/console assets:install, bin/console theme:compile.
• Problem: Plugin funktioniert nach Shopware-Update nicht mehr. Ursache: Plugin nutzt deprecated API oder ist nicht kompatibel. Lösung: Plugin-Update einspielen oder deaktivieren, Issue an Entwickler melden.
• Problem: Migration schlägt fehl. Ursache: DB-Inkonsistenz oder Custom-Code-Konflikt. Lösung: Migration-Log prüfen (var/log/), DB-State manuell korrigieren oder Migration skippen (nicht empfohlen, nur als Last-Resort).

Integrationen: Sync-Frequenzen, Daten-Mastering und Fehlerhandling

Integrationen sind kritisch für Datenkonsistenz und Prozess-Automation. Hier konkrete Umsetzungsmuster.

Daten-Mastering-Matrix

Sync-Frequenz-Empfehlungen

• Echtzeit: Bestände (kritisch für Kaufentscheidung), Bestellungen (schnelle Auftragsabwicklung), Tracking-Updates
• Stündlich: Preise (wenn häufig geändert), Verfügbarkeits-Status
• Täglich (nachts): Produktdaten (Texte, Attribute, neue Artikel), Kundendaten (B2B-Stammdaten)
• Wöchentlich: Kategoriestrukturen, Mediendaten (Bulk-Updates)

Shopware-6-Integrationsmuster

Pattern 1: Event-basiert (Echtzeit)

• ERP sendet Webhook bei Änderung (z. B. Bestand geändert), Shopware empfängt via Custom-Controller, aktualisiert Entity
• Shopware-Implementierung: Custom-Route (src/Controller/WebhookController.php), nutzt ProductRepository update()
• Fehlerhandling: Bei Fehler HTTP 500 zurückgeben, ERP retry (Webhook-Provider sollte Retry-Logic haben)

Pattern 2: Batch-Import (täglich/stündlich)

• ERP generiert Export-Datei (CSV, XML, JSON), legt auf SFTP/S3 ab, Shopware holt Datei, importiert per Symfony Command
• Shopware-Implementierung: Symfony Command (src/Command/ImportProductsCommand.php), nutzt Message-Queue für asynchrone Verarbeitung
• Fehlerhandling: Bei Fehler Zeile loggen, überspringen, Report am Ende (welche Zeilen fehlgeschlagen)

Pattern 3: API-Polling (bei fehlender Webhook-Unterstützung)

• Shopware fragt regelmäßig ERP-API ab (z. B. alle 5 Min.), holt geänderte Datensätze (Last-Modified-Timestamp nutzen)
• Shopware-Implementierung: Scheduled Task (src/ScheduledTask/SyncProductsTask.php), läuft alle X Minuten
• Fehlerhandling: Bei API-Fehler Retry mit Exponential-Backoff, Alerting bei dauerhaftem Fehler

Fehlerhandling-Best-Practices

• Retry-Logic: Bei transienten Fehlern (z. B. API-Timeout) automatisch wiederholen (max. 3x, Exponential-Backoff: 1s, 4s, 16s)
• Dead-Letter-Queue: Fehlgeschlagene Messages in separate Queue verschieben (manuelles Re-Processing möglich)
• Logging: Jede Integration loggen (Monolog nutzen, Log-Level: INFO für Success, ERROR für Fehler)
• Alerting: Bei kritischen Fehlern Alert senden (Slack, E-Mail, PagerDuty) – z. B. Bestandssync seit 2h fehlgeschlagen
• Monitoring: Dashboards für Sync-Jobs (Anzahl erfolgreiche/fehlgeschlagene Imports, Latenz, Queue-Länge)

Typische Integrations-Fehlerbilder

• Problem: Bestände im Shop stimmen nie. Ursache: Race-Condition (Shop aktualisiert Bestand, gleichzeitig ERP-Sync überschreibt). Lösung: Locking-Mechanismus (Pessimistic-Lock in Doctrine oder Redis-basiertes Lock).
• Problem: ERP-Sync dauert Stunden. Ursache: Sync läuft synchron, blockiert bei 100.000 Artikeln. Lösung: Message-Queue nutzen (Symfony Messenger), Artikel einzeln oder in Batches (100 Stück) asynchron verarbeiten.
• Problem: Bestellungen kommen nicht im ERP an. Ursache: Webhook fehlgeschlagen, kein Retry. Lösung: Shopware-Side: Webhook-Fehler loggen, Retry-Mechanismus (z. B. Cronjob prüft unübertragene Bestellungen).

Monitoring und Performance-Messpunkte

Ohne Monitoring fliegst du blind. Hier ein vollständiger Monitoring-Stack für Shopware 6.

Monitoring-Ebenen

Core-Web-Vitals-Messpunkte

• LCP (Largest Contentful Paint): Ziel unter 2,5s. Misst, wann größtes sichtbares Element lädt (oft Hero-Image oder Produktbild).
• FID (First Input Delay): Ziel unter 100ms. Misst Reaktionszeit auf ersten User-Input (z. B. Button-Klick).
• CLS (Cumulative Layout Shift): Ziel unter 0,1. Misst visuelle Stabilität (keine plötzlichen Layout-Verschiebungen).

Optimierung:

• LCP: Bilder komprimieren (WebP), Lazy-Loading, CDN nutzen, Server-Response-Time verbessern (unter 200ms TTFB)
• FID: JavaScript minimieren, Code-Splitting, nicht-kritisches JS asynchron laden
• CLS: Bild-Dimensionen angeben (width/height), keine dynamischen Inhalte ohne Platzhalter

Backend-Messpunkte (APM)

• Request-Latenz: P50, P95, P99 (z. B. P95 unter 500ms bedeutet: 95 % der Requests schneller als 500ms)
• DB-Queries: Anzahl Queries pro Request (Ziel: unter 50 für Produktliste, unter 20 für PDP), Slow-Query-Log aktivieren (MySQL: long_query_time=1)
• Cache-Hit-Rate: Redis Object-Cache (Ziel: über 90 %), HTTP-Cache (Ziel: über 70 %)
• Queue-Länge: Message-Queue (Ziel: unter 1000 Messages, sonst Worker-Kapazität erhöhen)

Infrastruktur-Messpunkte

• CPU: Average Load unter 70 % (Peaks bis 90 % OK, dauerhaft über 80 % skalieren)
• RAM: Unter 80 % genutzt (inkl. Cache), Swap sollte nicht genutzt werden
• Disk-I/O: I/O-Wait unter 10 %, SSD bevorzugt (NVMe für DB/Elasticsearch)
• Network: Bandwidth-Auslastung unter 70 %, Latenz zu externen APIs unter 100ms

Alerting-Regeln

• Critical (P1): Shop down (HTTP 500/503), DB down, Elasticsearch down, sofort Alert (PagerDuty, SMS)
• High (P2): Conversion-Rate -30 % (vs. Vortag), Error-Rate über 5 %, Queue-Länge über 5000, Alert innerhalb 15 Min.
• Medium (P3): LCP über 4s, Slow-Queries über 100 pro h, Alert innerhalb 1h

Zusammenfassung und nächste Schritte

Du hast jetzt technische Tiefe zu Hosting-Topologien, Caching-Strategien, Elasticsearch-Konfiguration, Plugin-Governance, Release-Strategien, Integrations-Mustern und Monitoring-Stack. Diese Entscheidungsleitplanken helfen dir, Shopware-6-Projekte fundiert zu planen und zu betreiben.

Checkliste für dein nächstes Projekt

• Hosting-Topologie wählen (Single-Server, Load-Balanced, Kubernetes) basierend auf Traffic und Skalierungsanforderungen
• HTTP-Cache konfigurieren (Varnish für Production, Tag-basierte Invalidierung sicherstellen)
• Elasticsearch/OpenSearch aufsetzen (3-Node-Cluster für Production, Index-Tuning, Relevanz-Optimierung) – als Ergänzung lohnt sich der Deep-Dive zu Elasticsearch in Shopware 6.
• Plugin-Governance definieren (Qualitätskriterien, Approval-Prozess, Update-Zyklus)
• Release-Strategie festlegen (Staging, Blue-Green oder Canary, Rollback-Plan)
• Integrationen planen (Daten-Mastering-Matrix, Sync-Frequenzen, Fehlerhandling, Monitoring)
• Monitoring-Stack aufbauen (RUM, APM, Infrastruktur, Logs, Business-KPIs, Alerting)