Commerce-Plattform: Skalierbarkeits-Design für Peak-Traffic im B2B-Handel

B2B-Commerce-Plattformen stehen und fallen mit Peak-Traffic-Tagen. Im Gegensatz zum Consumer-E-Commerce, wo Traffic-Peaks breit vorhersehbar sind (Black Friday, Feiertagssaison), werden B2B-Commerce-Peaks von Geschäftszyklen getrieben: Beschaffungsrushes am Quartalsende, jährliche Vertragsverlängerungen, Messebestellereignisse und Saisonkampagnen, die mit Tagen statt Monaten Vorankündigung eintreffen können. Dekas Commerce-Plattform ist für diese Muster konstruiert — und die hier beschriebene Skalierbarkeitsarchitektur wurde gegen ein 10-faches Traffic-Ereignis während der jährlichen Beschaffungskampagne eines Kunden validiert.

B2B-Traffic-Muster verstehen

B2B-Commerce-Traffic ist insgesamt spitziger und vorhersehbarer als Consumer-Traffic, aber weniger vorhersehbar im Timing. Die Einkaufsabteilung eines Herstellers kann 80 % ihres monatlichen Bestellvolumens in den letzten drei Tagen des Monats generieren. Die Jahreskonferenz eines Distributors erzeugt das 5-fache normale Bestellvolumen in einem 48-Stunden-Fenster. Ein ERP-integriertes Beschaffungsportal kann Traffic-Spitzen nicht von menschlichen Nutzern, sondern von automatisierten Beschaffungssystemen erfahren, die Sammelbestellungen gleichzeitig aufgeben.

Unsere Plattform-Instrumentierung sammelt Traffic-Muster pro Kunde, identifiziert Peak-Event-Signaturen und verwendet diese Daten, um Autoscaling-Parameter proaktiv zu kalibrieren. Wir warten nicht auf Peaks, um zu entdecken, dass sie die Kapazität überschreiten.

Auto-Scaling-Architektur auf Kubernetes

Die Commerce-Plattform läuft auf Kubernetes mit einer dreilagigen Auto-Scaling-Strategie:

• Horizontal Pod Autoscaler (HPA): Skaliert individuelle Service-Deployments basierend auf CPU und benutzerdefinierten Anwendungsmetriken (Request-Queue-Tiefe, aktive Sessions). HPA operiert mit einem 15-Sekunden-Bewertungsintervall und einem 3-Minuten-Scale-Down-Stabilisierungsfenster zur Vermeidung von Thrashing.
• Cluster Autoscaler (CA): Fügt dem zugrundeliegenden Kubernetes-Cluster basierend auf Pod-Scheduling-Druck Nodes hinzu und entfernt sie. Wir verwenden Node-Pools mit verschiedenen Instance-Größen — Baseline-Pool für Steady-State-Traffic, Burst-Pool mit größeren Instances für Peak-Events.
• KEDA (Kubernetes Event-Driven Autoscaling): Für Bestellverarbeitungs-Worker, die aus Message-Queues konsumieren, skaliert KEDA Worker-Pods direkt basierend auf Queue-Tiefe. Wenn ein Massenbestellimport-Event die Queue-Tiefe über den Schwellenwert treibt, skaliert KEDA Worker innerhalb von 30 Sekunden.

Redis-Caching-Schichten

Die Commerce-Plattform implementiert drei Redis-Caching-Schichten, jede mit unterschiedlichen TTL- und Invalidierungsstrategien:

• Produktkatalog-Cache: Katalogdaten, Preise und Verfügbarkeit — TTL von 5 Minuten mit ereignisgesteuerter Invalidierung bei Admin-Updates. Diese Schicht absorbiert den Großteil des Read-Traffics unter Spitzenlast.
• Session- und Warenkorb-Cache: Aktive Nutzersessions und Warenkörbe — TTL von 30 Minuten mit gleitendem Ablauf. Redis Cluster für HA; Warenkorb-Daten werden auch asynchron in die primäre Datenbank persistiert.
• Berechnete Aggregat-Cache: Bestellhistorie-Zusammenfassungen, kontoebenenspezifische Preisregeln, Genehmigungs-Workflow-Status — bei Schreibvorgang berechnet und gecacht bis zur Invalidierung durch das relevante Schreibereignis.

Unsere Cache-Hit-Ratio unter Spitzenlast beträgt durchschnittlich 94 % für Katalog-Reads. Bei 10-fachem normalem Traffic verhindert diese Ratio etwa 90.000 zusätzliche Datenbanklesevorgänge pro Minute, die die primäre Datenbankschicht erreichen — der Unterschied zwischen eleganter Verarbeitung und Kaskadenausfall.

Datenbank-Read-Replicas und Verbindungsmanagement

Der primäre Datenbank-Cluster (PostgreSQL auf verwalteter Cloud-Infrastruktur) wird durch PgBouncer-Verbindungs-Pooling vorgeschaltet, wobei Read-Replicas alle nicht-transaktionalen Lesevorgänge verarbeiten. Während Peak-Traffic-Events skaliert die Anzahl der Read-Replicas automatisch via Cloud-Provider-APIs, ausgelöst durch CloudWatch/Azure-Monitor-Metriken. Schreiboperationen gehen ausschließlich an das Primärsystem, geschützt durch Verbindungslimits und Query-Timeout-Enforcement. Langläufige Berichte und Exporte werden in die Warteschlange gestellt und gegen dedizierte schreibgeschützte Replicas ausgeführt, die vom Transaktionspfad isoliert sind.

CDN-Strategie und Lasttests

Statische Assets und Katalogbilder werden ausschließlich von CDN-Edge-Nodes (Cloudflare) ausgeliefert, mit Cache-Control-Headern, die für maximale CDN-Cache-Hit-Rates optimiert sind. API-Antworten, die sicher gecacht werden können (Produktsuchergebnisse, Kategoriebäume), tragen Cache-Control: public, max-age=300-Header für CDN-Caching am Edge.

Vor jedem großen Peak-Event führen wir Lasttests mit k6 durch, die das 10-fache der erwarteten gleichzeitigen Nutzer mit realistischen Bestellplatzierungs-Flows simulieren. Das Test-Suite umfasst Ramp-up-Szenarien, anhaltende Peak-Szenarien und Spike-Szenarien (sofortiger Sprung auf Peak). Unser Lasttest-Ziel für die Commerce-Plattform ist die Verarbeitung von 100 % des erwarteten Peak-Traffics innerhalb der P95-Latenz-SLAs, ohne 5xx-Antworten. Das oben referenzierte 10-fache Ereignis wurde von einem Lasttest vorausgegangen, der genau den Engpass vorhersagte — ein Verbindungspool-Limit bei einem Drittanbieter-Zahlungsgateway — der vor Beginn des Ereignisses behoben wurde.