Magento 2 Entwicklung: Architektur, Module, Themes & Schnittstellen im Überblick

Magento 2 Architektur-Entscheidungen, die später über Wartbarkeit und Kosten entscheiden

Welche Architekturentscheidung zahlt sich in Magento 2 am stärksten aus?

Triff früh eine harte Wahl: Edition, Frontend-Architektur, und eine Customizing-Disziplin mit Budget. Danach wird alles günstiger. Oder deutlich teurer.

Was ist der Unterschied zwischen Magento Open Source und Adobe Commerce? Magento Open Source ist die kostenfreie Magento-Edition mit Kernfunktionen für Commerce; Erweiterungen und Betrieb liegen in eigener Verantwortung. Adobe Commerce ist die kommerzielle Magento-Edition (ehem. Magento Commerce) mit zusätzlichen Features (z.

B2B, Staging, Support) und Adobe-Lizenzmodell.

Die Feature-Deltas sind nicht kosmetisch. B2B (Company Accounts, Quotes, Shared Catalog) ist oft ein Programm, kein Ticket.

Staging ändert Deployment- und Content-Prozesse, weil Kampagnen nicht mehr nur Release-Artefakte sind. Support ist kein „nice to have“, sondern eine Risiko-Option: du kaufst Reaktionszeit und Eskalation, nicht bessere Architektur.

Heuristik. Wenn du B2B wirklich brauchst, nimm Adobe Commerce. Wenn du primär D2C bist und dein Team Patch Management, Monitoring und Betrieb beherrscht, reicht Magento Open Source oft. Wenn du diese Betriebsreife nicht hast, wird „Lizenz sparen“ schnell zur Latenz- und Stabilitätssteuer.

Frontend als Kostentreiber. Klassisch (Luma/Hyvä/Custom Theme) koppelt Release-Zyklen stark an Magento-Deployments; SEO ist direkter, Caching über Full Page Cache (FPC) und Varnish ist klarer, und TTFB lässt sich brutal gut drücken. Headless über GraphQL verschiebt Arbeit in Resolver, Caching-Strategien, Edge, und invalidation; dafür entkoppelst du UI-Releases vom Backend, wenn du Disziplin hast.

Wenn nicht, baust du zwei Monolithen. Lies dazu: Headless-Optionen in Magento: PWA Studio vs. Framework-Frontend.

Team-Skills sind das Gate. Theme-getrieben braucht tiefes Magento-Layout/JS-Build-Know-how und Performance-Handwerk. Headless braucht API-first-Denken, GraphQL Resolver-Design, Circuit Breaker an Integrationskanten, und saubere Idempotenz bei Writes, sonst eskaliert die Queue (Message Queue) und Cron wird zur Fehler-Müllhalde.

Fair enough.

Customizing-Prinzipien. Plugin (Interceptor) zuerst.

Preference fast nie. Observer/Event selektiv.

// Plugin (Interceptor): lokal, konfliktarm, upgrade-freundlicher
aroundPlaceOrder(subject, proceed, cartId) {
  validate(cartId)
  return proceed(cartId)
}

// Preference: globale Ersetzung, hoher Konflikt- und Upgrade-Risiko-Faktor
<preference for="Vendor\X\Service" type="Vendor\Y\ServiceOverride"/>

// Observer/Event: gut für Nebenwirkungen, aber Reihenfolge/Idempotenz beachten
on("sales_order_place_after", event) {
  publishToQueue(event.orderId) // idempotent machen
}

Konflikte passieren leise. Zwei Plugins um dieselbe Methode sind meist noch debuggbar. Zwei Preferences sind Krieg. Observer können doppelt feuern, wenn Retries oder Replays passieren; ohne Idempotenz entstehen Dubletten, falsche Bestände, kaputte Indexer.

Setz ein Customizing-Budget. Fixe Obergrenze pro Quartal. Harte Modulgrenzen. Service Contracts für alles, was andere Module konsumieren.

API-first für Integrationen. Keine Core-Hacks.

Klingt einfach. Ist es nicht.

Das funktioniert. Punkt.

Feature-Umsetzungen aus der Praxis: B2B-Preislogik, MSI und Checkout-Customizing (inkl. Vorgehen & Ergebnis)

[2026-02-12T09:14:22.113Z] main.ERROR: Quote price mismatch. expected=128.52 actual=128.50 sku=ABC-42 customer_group=contract_net

Der Preis ist falsch, weil Preisfindung verteilt ist. Und weil Rundung selten dort passiert, wo du sie erwartest.

Ein Kollege hat letztens genau diesen Fehler gemacht. Er hat nur im Produktlisting korrigiert. Im Warenkorb blieb der alte Pfad aktiv, inklusive anderer Steuerlogik und anderer Währungskonvertierung.

Praxisfall 1: B2B-Preislogik. Vertrags- und Staffelpreise, Kundengruppen, Nettopreise, Rundung. Das gehört in eine klare Kette: Produktpreis → Regelwerk → Quote Item → Totals. Kurz. Hart.

Implementierung: Preisberechnung in einem isolierten Modul, mit Service-Klasse und kleinem Plugin an der Preis-API. Kein Wildwuchs in Templates. Catalog Rules nur, wenn das Regelmodell passt; sonst wird es untestbar, weil Rule-Indexer und Cache dazwischenfunken.

bin/magento module:status Vendor_B2bPricing
bin/magento setup:upgrade
bin/magento cache:flush

<?php
// etc/di.xml
// Plugin (Interceptor) statt Preference, damit Konflikte lokal bleiben.
namespace Vendor\B2bPricing\Plugin;

class PriceResolverPlugin
{
    public function aroundResolve(
        \Magento\Catalog\Model\Product\Type\Price $subject,
        callable $proceed,
        \Magento\Catalog\Model\Product $product
    ) {
        $base = $proceed($product);

        // Vertrags-/Staffelpreis anhand Kundengruppe + Vertrags-ID aus Extension Attributes.
        // Rundung NACH Steuer- und Währungslogik, aber VOR Quote-Totals.
        return $this->rounder->round($this->contractPrice->apply($product, $base));
    }
}

Tests: Preis-Assertions auf drei Ebenen.

Produkt-API. GraphQL Resolver. Quote-Totals. Jede Ebene hat andere Stolpersteine, weil Cache, Indexer und Persistenz anders greifen.

<?php
public function testContractNetPriceIsStable()
{
    $price = $this->priceService->getNetPrice('ABC-42', 'contract_net', 12);
    $this->assertSame('128.52', number_format($price, 2, '.', ''));
}

Stolpersteine: Indexer invalidiert Regeln nicht, wenn Vertragsdaten extern gepflegt werden. Dann liefert FPC alte Preise.

API-Clients cachen zusätzlich. Ergebnis: Support-Tickets.

Zielwerte, realistisch: 20–40% weniger Preis-Differenz-Tickets nach zwei Releases. Release-Frequenz von monatlich auf wöchentlich, weil die Preislogik versioniert und testbar ist (ja, auch hier). Latenz bleibt stabil, weil keine DB-Scans in Requests.

Wie erstellt man ein Magento 2 Modul bzw.

eine Erweiterung? Minimal: composer.json, registration.php, etc/module.xml. Dann DI, Events, Setup nur wenn nötig. Fertig.

<?php
// registration.php
use Magento\Framework\Component\ComponentRegistrar;
ComponentRegistrar::register(
    ComponentRegistrar::MODULE,
    'Vendor_B2bPricing',
    __DIR__
);

Praxisfall 2: Multi-Source Inventory (MSI). Source ist physisch. Stock ist verkaufsfähig. Reservationen sind Buchungen, nicht Bestand.

Das Missverständnis killt Throughput im Fulfillment.

Click&Collect: eigene Source, eigene Priorität, oft eigene Backorders-Policy. Reservationen müssen idempotent sein, weil Retries in der Queue (Message Queue) normal sind. Sonst entstehen Phantom-Reservierungen und negative Salable Quantities.

Ergebnis?

ERP/WMS-Integration: synchron nur für Verfügbarkeit lesen. Schreiben immer asynchron. Sonst hängt Checkout an WMS-Latenz und du siehst es direkt in TTFB.

MSI-Fluss	Pattern	Messgröße
Order platziert → Reservation	Event-Driven + Queue, idempotente Consumer	Fehlgeschlagene Reservations < 0,1%
WMS Pick bestätigt → Source Deduction	Async Command, Retry mit Dedup-Key	Bestands-Drift < 0,5%

Praxisfall 3: Checkout-Customizing. UI Components, JS, Payment/Shipping. Validierungen gehören in UI und Server.

Doppelt. Absichtlich.

Ein neues Feld im Checkout? UI Component mit sauberem dataScope, plus Server-Validation im Quote-Submit. Payment-Provider: Request-Signing und Timeout-Handling, sonst blockierst du INP durch lange Main-Thread-Tasks und wartende XHR.

// requirejs mixin: Validierung ohne Core-Override
define([], function () {
  'use strict';
  return function (target) {
    return target.extend({
      validate: function () {
        var ok = this._super();
        return ok && (this.source.get('checkout.custom.company_vat') || '').length > 0;
      }
    });
  };
});

Messen: TTFB im Checkout über Varnish-Bypass ist normal hoch, aber kontrollierbar. INP ist der Killer bei schweren UI Components.

Ziel: ```typescript // Basis-Konfiguration – anpassen je nach Umgebung export const config = { environment: 'production', apiEndpoint: 'https://api.example.com', timeout: 5000, // 5s reicht für die meisten APIs retries: 3 // Exponential backoff empfohlen }; ``` INP 200–350ms im Checkout auf typischen Geräten, statt 600–900ms nach ungebremstem Customizing. Checkout-Abbrüche sinken oft um 5–12%, wenn Payment-Redirects stabil und Validierungen klar sind.

Dann kommt Security. Patch Management wird Teil der DoD. Ohne Diskussion.

Performance & Skalierung: Cache-Topologien, Search-Setup, DB-Tuning und Core Web Vitals als Zielsystem

Man erwartet: mehr CPU, mehr RAM, Problem gelöst. In Magento 2 passiert oft das Gegenteil: mehr Hardware kaschiert nur Cache-Misses.

Typisches Startproblem: Kategorie-Requests pendeln bei 1,8–3,5s, obwohl Varnish aktiv ist. Der FPC-Hit ist niedrig. Die DB wird heiß.

Referenz-Topologie, die in echten Shops trägt: Nginx/PHP-FPM hinter Varnish (Full Page Cache), Redis Cache/Session, OpenSearch/Elasticsearch für Suche; RabbitMQ optional für Queue (Message Queue). Varnish ist zwingend, sobald Traffic oder Katalog groß werden und TTFB stabil bleiben muss. Redis ist praktisch immer zwingend, weil File-Cache und DB-Sessions unter Last kollabieren.

OpenSearch/Elasticsearch ist zwingend für produktive Suche. RabbitMQ ist zwingend, wenn Integrationen, Imports oder E-Mails Backpressure brauchen.

Warum ist das so? Weil Skalierbarkeit zuerst aus Entkopplung entsteht, nicht aus mehr Threads.

Konfigurationspunkte, die sofort messbar wirken: Cache-Backends auf Redis, Sessions auf Redis, FPC über Varnish mit sauberer TTL-Strategie. TTL ist kein Dogma. Sie ist ein Vertrag zwischen Content-Frequenz und Hit-Rate.

Was heißt das konkret?

# app/etc/env.php (Auszug)
'cache' => [
  'frontend' => [
    'default' => ['backend' => 'Cm_Cache_Backend_Redis'],
    'page_cache' => ['backend' => 'Cm_Cache_Backend_Redis']
  ]
],
'session' => ['save' => 'redis'],
'http_cache_hosts' => [['host' => 'varnish', 'port' => '80']]

Varnish ohne VCL-Disziplin ist nur ein Reverse Proxy. Setze TTL pro Content-Typ, und halte Invalidations klein.

// VCL-Idee: harte Defaults vermeiden, Edge-Cache bewusst steuern
sub vcl_backend_response {
  if (bereq.url ~ "^/media/") { set beresp.ttl = 7d; }
  elseif (bereq.url ~ "^/static/") { set beresp.ttl = 30d; }
  else { set beresp.ttl = 10m; }
}

Die Frage „Wie verbessert man die Performance von Magento 2 (Varnish, Redis, Indexer)?“ beantwortet sich in Reihenfolge: erst Hit-Rate, dann Indexer, dann DB. Nicht andersrum.

Was sagen die Daten?

Indexer: on-save ist für kleine Kataloge okay. Bei großen Katalogen frisst es Checkout-Latenz. Scheduled entkoppelt, braucht aber Cron-Health und Idempotenz in Customizing-Observern.

# Indexer auf scheduled, damit Writes nicht Reads vergiften
bin/magento indexer:set-mode schedule
bin/magento indexer:status

Cron ist dein stiller SPOF. Prüfe Laufzeiten, Staus, und Retry-Strategie. Ein Cron-Backlog macht Preise „random“ und Suche „alt“.

# Cron-Health: Drift und Stau sichtbar machen
bin/magento cron:run
tail -n 200 var/log/cron.log
tail -n 200 var/log/support_report.log

Suche langsam nach Update? Klassiker: Analyzer/Mapping geändert, Reindex läuft, Query-Performance fällt, und der Index wird zu groß. Miss: 95p Search-Response-Time, Heap, Segment-Count.

Warum?

Search-Tuning ist ein Bounded Context. Pflege Synonyme und Stopwords versioniert. Teste Relevanz mit fixen Query-Sets, nicht mit Bauchgefühl. Analyzer-Änderungen sind Breaking Changes für den Index.

Metrik	Zielwert (Startpunkt)	Priorität
Cache-Hit-Rate (FPC)	> 85% Katalog, > 60% PLP	1
TTFB (cached)	100–300ms	2
95p Response Time (uncached)	< 1,2s Katalog	3
DB Slow Queries	< 1% Requests > 200ms	4
LCP/INP/CLS	LCP < 2,5s, INP < 200–350ms, CLS < 0,1	5

Monitoring-Setup: APM (Transaction Traces für PHP-FPM, Redis, OpenSearch/Elasticsearch), plus strukturierte Logs mit Correlation-ID. Ergänze Varnish-Logs für Hit/Miss und Backend-Response. Ohne das optimierst du im Dunkeln.

Warmup/Priming nach Zero-Downtime Deployment ist Pflicht.

Cache-Warmup reduziert TTFB-Spikes nach Release. Das funktioniert. Punkt.

Und Frontend? Es bleibt Zielsystem, nicht Startpunkt. Lies dazu Core Web Vitals und warum Speed direkt auf Conversion einzahlt, aber nur nachdem Backend und Cache stabil sind.

In einem Projekt mit hoher Last haben wir genau dieses Problem gesehen: Suche wurde nach jedem Synonym-Update langsam, weil der Index wuchs und Segmente explodierten. Lösung war kein „Tuning“, sondern ein kontrollierter Reindex-Fensterplan, Circuit Breaker für Search-Timeouts, und harte Budgets für Index-Größe.

DevOps, Deployments und Security: So bleibt Magento 2 updatefähig (und nachts ruhig)

Warum bricht das Deployment erst nach dem Composer-Update auf Staging?

Weil dein Release kein reproduzierbares Artefakt ist, sondern ein Live-Experiment mit Netzwerk, Secrets und Zufall.

Der Rückbezug ist simpel: Wenn Warmup Pflicht ist, dann ist ein deterministischer Build Pflicht. Sonst jagst du TTFB-Spikes und 500er.

CI/CD-Blueprint. Hart. Ohne Tool-Fetisch.

• Build-Job erzeugt Artefakt: vendor/, generierter Code, statische Assets, Version-Stamp.
• composer install --no-dev --prefer-dist --no-interaction strikt gegen composer.lock.
• bin/magento setup:di:compile und setup:static-content:deploy im Build, nicht auf dem Zielhost.
• Config Split über app/etc/config.php; Umgebungswerte nur in env.php.
• Secrets kommen aus Vault/CI-Secret-Store. Niemals im Repo. Niemals im Artefakt.

# Build (CI)
composer install --no-dev --prefer-dist --no-interaction
php -d memory_limit=2G bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f de_DE en_US
tar -czf release.tgz vendor generated pub/static pub/media app/etc/config.php

env.php ist Deployment-Input. Punkt. Du templatisierst ihn, du commitest ihn nicht.

# Deploy (Target)
tar -xzf release.tgz -C /var/www/releases/$RELEASE
ln -sfn /var/www/shared/env.php /var/www/releases/$RELEASE/app/etc/env.php

Release-Strategie: symlink releases oder Blue/Green (und das ist noch die einfache Version). Beides braucht Rollback in Sekunden, nicht Minuten.

# Atomic switch + rollback
ln -sfn /var/www/releases/$RELEASE /var/www/current
# rollback
ln -sfn /var/www/releases/$PREV /var/www/current

Zero-Downtime heißt: Maintenance-Mode nur für DB-Schritte. Alles andere passiert davor oder danach.

Declarative Schema ist dein Hebel. Trotzdem: große DDL-Änderungen sind riskant, weil Locks Throughput töten.

Plane Migrationsstrategie: additive Changes zuerst, Backfill via Cron oder Queue (Message Queue), dann Umschalten. Backpressure ist gewollt.

Indexer und Cron koordinierst du explizit. Keine Überraschungen.

• Vor Switch: bin/magento cron:remove oder Service stoppen.
• Nach Switch: cron:install, dann gezielt indexer:reindex oder scheduled lassen.
• Cache-Warmup triggert URLs, die FPC füllen; Varnish und Redis Cache/Session müssen sauber sein.

Security-Baseline ist Prozess, nicht Plugin.

• Patch Management nach Adobe Security Bulletins: bewerten, testen, ausrollen, nachverfolgen.
• 2FA aktiv, Admin-URL nicht default, ACL minimal, WAF-Regeln versioniert.
• Hardening: Dateirechte restriktiv, app/etc und var korrekt, kein Schreibrecht für Code.
• Dependency Audits: composer audit plus Allowlist für False Positives.

# Security checks (CI)
composer validate --strict
composer audit
bin/magento security:recaptcha:disable  # nur falls bewusst, sonst nicht anfassen

Troubleshooting. Symptome → Ursache → Fix.

Symptom	Wahrscheinliche Ursache	Fix
Composer löst auf Dev anders als Staging	Lockfile drift, Plattform-PHP-Extensions, private Repos	composer.lock erzwingen, config.platform setzen, Auth via CI-Secrets
DI Compilation Errors nach Update	Plugin (Interceptor) auf geänderte Signatur, Preference-Konflikt	Module isolieren, bin/magento module:disable, Konflikt via di.xml auflösen
Cache/Indexer “stuck”, CPU hoch	Indexer scheduled ohne Cron, Deadlocks, zu große Batches	Cron prüfen, indexer:reset, Batches reduzieren, DB-Locks analysieren
Suche 503/Timeout	OpenSearch/Elasticsearch unreachable, falsches TLS, Circuit Breaker fehlt	Connection testen, Timeouts setzen, Retry-Strategie mit Jitter, Fallback-UX
Login hängt, Sessions frieren ein	Redis Session Locks, lange Requests, fehlendes Session-Backend-Tuning	Locking konfigurieren, langsame Requests killen, PHP-FPM/Redis Timeouts anpassen

3rd-Party-Module-Konflikte behandelst du wie Produktionsfehler.

Version pinnen. Changelog lesen. Notfalls raus.

Und wenn ein Update nur mit Preference “geht”, ist das kein Fix. Das ist ein zukünftiger Incident.

Projektmodell & Team-Setup einer Magento-2-Agentur: Rollen, DoD, Qualitätssicherung – mit Mini-Case (Relaunch/Migration)

Ein Magento-2-Relaunch wird nur planbar, wenn Rollen, Übergaben und QA-Gates härter sind als das Customizing.

Nach Modul-Konflikten und riskanten DI-Ersatzmechanismen brauchst du kein Heldentum, sondern ein belastbares Projektmodell. Event-Driven Integrationen, Queue (Message Queue) und Cron erhöhen Throughput.

Sie erhöhen aber auch die Anzahl möglicher Failure-Modes. Wer das ohne DevOps und QA betreibt, produziert Latenz und Incidents.

Rolle	Verantwortung	Übergabe/Artefakt
Solution Architect	Architektur, ADRs, Integrations- und Datenmodell, Performance-Budgets	ADR + Non-Functional Requirements, Review-Freigabe für kritische PRs
Backend	Modul-Design, Service Contracts, Indexer/Cron/Queue, GraphQL Resolver	Code + Unit/Integration-Tests, Migrationsskripte, API-Doku
Frontend	Theme, Layouts, Templates, JS, Core Web Vitals	Performance-Budget-Checks, LCP/INP-Fixes, Komponenten-Doku
QA	Teststrategie, E2E-Suites, Regressions, Release-Sign-off	QA-Gate-Report, Bug-Triage, Freigabeprotokoll
DevOps	CI/CD, Zero-Downtime Deployment, Observability, Patch Management	Pipeline + Rollback-Plan, Monitoring-Dashboards, Runbooks
PM	Scope, Risiko-Management, Stakeholder, Release-Plan	Roadmap, Cutover-Checkliste, Go/No-Go-Entscheidung

Die Definition of Done (DoD) ist nicht verhandelbar. Punkt.

• PR-Review: 2-Augen, Architekt bei DI/Indexer/Checkout-Pfaden.
• Testpyramide: Unit fängt Logik, Integration fängt Magento-IO, E2E schützt Flows.
• QA-Gates: Security-Scan, Performance-Smoke, Reindex/Cron-Health, Deploy-Probe.
• Release-Steuerung: Frequenz pro Sprint, Bug-Rate pro Release als KPI.

# Minimaler PR-Gate in CI (Pseudo)
composer validate
vendor/bin/phpunit --testsuite unit
vendor/bin/phpunit --testsuite integration
vendor/bin/mftf run:test AdminLogin CheckoutGuest
bin/magento cache:flush && bin/magento indexer:reindex

Wie lange dauert die Entwicklung oder ein Relaunch mit Magento 2? 8–16 Wochen für einen fokussierten Relaunch, 4–9 Monate bei Migration plus komplexen Integrationen.

Mini-Case. Migration von einem Legacy-Shop auf Magento Open Source, 120k Kunden, 900k Bestellungen, 40k SKUs, Such-Stack auf OpenSearch/Elasticsearch, FPC via Varnish, Redis Cache/Session.

Constraint eins: SEO darf nicht fallen. Constraint zwei: Cutover in einer Nacht. Constraint drei: Bestellhistorie muss vollständig bleiben.

Sieht man das im Monitoring?

# Datenmigration: inkrementell, idempotent (Pseudo)
migrate:customers --since "2025-10-01T00:00:00Z" --upsert
migrate:orders    --since "2025-10-01T00:00:00Z" --upsert
verify:counts --entity customers,orders --source legacy --target magento

Entscheidung: Redirect-Strategie als First-Class-Artefakt. Keine Excel-Hölle. Eine versionierte Mapping-Datei, getestet wie Code.

# Redirect-Mapping (Beispiel, CSV)
from,to,code
/produkt/alt-123,/p/neuer-slug-123,301
/kategorie/sale,/sale,301

Cutover-Plan: Freeze-Fenster, Delta-Migration, DNS-Switch, Warmup, Monitoring, dann Go/No-Go. Die Retry-Strategie für Queue-Consumer war vorab definiert, inklusive Dead-Letter-Handling. Das reduziert Incident-Druck.

# Queue Consumer: Retry/Backoff (Pseudo-Konfig)
consumer:
  name: order_export
  max_retries: 8
  backoff: exponential
  dlq: order_export_failed

Outcome, messbar: Stabilität über 14 Tage ohne Severity-1, TTFB im Cache < 120ms, LCP von 3,1s auf 1,9s, INP unter 200ms. Conversion bewegte sich je nach Kanal zwischen +2% und +6%.

Kurzer Hinweis: Die genauen Zahlen hängen natürlich vom konkreten Setup ab.

Nicht vergessen: Immer erst in Staging testen. Immer.

Kleine Randbemerkung: Das hat bei uns 2 Tage gedauert, bis es stabil lief.

Wenn du ein Team-Setup gegenprüfen willst, nimm dieses Referenz-Setup als Vergleich: Magento-Agentur in Stuttgart: Beratung, Relaunch und Support als Referenz-Setup.

Wenn du konkrete Nachweise brauchst statt Versprechen: Architektur-Review, Performance-Audit und einen belastbaren Relaunch-Plan bekommst du über die Magento Agentur.