Millionen Produkte, null Downtime

01.04.2026: Performance-Probleme bei großen B2B-Katalogen haben selten eine einzelne Ursache. Meist ist es eine Kombination: Die Suche durchsucht bei jeder Anfrage den gesamten Bestand live. Preise werden bei jedem Seitenaufruf aus dem ERP berechnet. Facettenfilter aggregieren über Millionen Datensätze ohne Vorberechnung. Produktlisten laden 50 Attribute pro Artikel, obwohl nur 5 angezeigt werden. Und nachts läuft ein Batch-Import, der den Index für zwei Stunden blockiert.

Was B2B-Kataloge besonders macht

• Technische Tiefe der Daten: Ein Kugellager hat nicht „Farbe: Rot" als Attribut, sondern Innendurchmesser, Außendurchmesser, Breite, Tragzahl, Drehzahlgrenze, Werkstoff, Dichtung, Schmierung - in Dutzenden Kombinationen. Das multipliziert sich über 2 Millionen Artikel.
• Kundenspezifische Sicht: Kunde A sieht andere Preise als Kunde B. Manche Produkte sind für bestimmte Kundengruppen gesperrt. Verfügbarkeiten variieren je nach Lieferwerk. Das macht Caching deutlich komplexer als im Endkundengeschäft.
• Varianten und Konfigurationen: Ein Grundprodukt kann 500 Varianten haben - jede mit eigener Artikelnummer, eigenem Preis, eigenem Lagerbestand. Die Suche muss das abbilden, ohne 500-mal dasselbe Produkt anzuzeigen.
• Datenqualität aus Altsystemen: Produktdaten kommen aus ERPs, PIMs, Excel-Dateien, Lieferantenkatalogen - in unterschiedlichen Formaten, Sprachen und Qualitätsstufen. Fehlende oder inkonsistente Attribute torpedieren jede Suche und Filterung.
• Parallele Datenquellen: Stammdaten aus dem PIM, Preise aus dem ERP, Lagerbestände aus dem WMS, Bilder aus dem DAM. Die Herausforderung: Alles muss schnell zusammenfließen - nicht erst bei der Abfrage, sondern bereits vorher.
  
  

Warum "einfach Elasticsearch draufwerfen" nicht reicht

Elasticsearch oder OpenSearch sind mächtige Werkzeuge - aber bei 2 Millionen Produkten mit komplexen Attributen wird die Standardkonfiguration zum Engpass. Das Problem ist nicht die Technologie, sondern das Datenmodell: Wie werden Varianten indexiert? Wie fließen kundenspezifische Preise ein? Wie werden Facetten vorberechnet, statt bei jeder Anfrage live aggregiert zu werden? Ein guter Suchindex für B2B-Kataloge ist ein eigenständiges Engineering-Projekt - kein Plugin, das man aktiviert.

Das Batch-Problem

In vielen Unternehmen werden Produktdaten, Preise und Bestände nachts per Batch-Job importiert. Das bedeutet: Tagsüber arbeiten Kunden mit veralteten Daten. Ein Produkt ist ausverkauft, aber der Shop zeigt „verfügbar". Ein Preis wurde geändert, aber der Kunde sieht den alten. Und wenn der nächtliche Import fehlschlägt, bemerkt es erst der Einkäufer am nächsten Morgen – durch eine falsche Bestellung.

Wie eine Suche für 2 Millionen Produkte aussehen muss

• Denormalisierte Indizes: Statt bei jeder Suchanfrage Daten aus fünf Systemen zusammenzusuchen, werden alle relevanten Informationen vorab in den Suchindex geschrieben -  Stammdaten, Verfügbarkeiten, Kategorien. Der Index enthält alles, was für die Anzeige nötig ist, in einem einzigen Dokument pro Produkt.

• Kundenspezifische Preise: Nicht jeder Preis muss im Index vorgehalten werden - bei Millionen von Preis-Kunden-Kombinationen wäre das unverhältnismäßig aufwendig. Oft ist ein performanter Live-Call auf einen optimierten ERP-Endpunkt die bessere Lösung: Nur die Preise, die der Kunde tatsächlich anfragt, werden in Echtzeit geladen. Für Kundengruppen mit festen Preislisten können ergänzend vorberechnete Segmente im Index geführt werden.

• Intelligente Facettierung: Facettenfilter (z. B. „Innendurchmesser: 20mm") werden nicht bei jeder Anfrage über den gesamten Bestand berechnet, sondern über vorberechnete Aggregationen. Das reduziert die Antwortzeit bei gefilterten Suchen von mehreren Sekunden auf den Millisekundenbereich.
• Varianten intelligent zusammenfassen: 500 Varianten eines Grundprodukts werden im Index als ein Dokument mit verschachtelten Variantendaten abgebildet - so erscheint in der Trefferliste ein Ergebnis mit Variantenauswahl, nicht 500 einzelne Treffer.
• KI-gestützte Suche: Ergänzend zur klassischen Volltextsuche setzen wir auf semantische Suchmodelle, die Fachbegriffe und Synonyme verstehen. „V2A-Senkkopf 8mm" findet auch „Edelstahlschraube M8 rostfrei" - ohne manuell gepflegte Synonymlisten.

Index-Pipeline: Vom Rohwert zum suchbaren Dokument

Die Index-Pipeline ist das Herzstück der Sucharchitektur. Sie nimmt Rohdaten aus PIM, ERP und WMS entgegen, transformiert, anreichert und normalisiert sie – und schreibt das Ergebnis als suchfertiges Dokument in den Index. Diese Pipeline läuft ereignisbasiert: Jede Änderung an einem Produkt, Preis oder Bestand löst eine Neuindexierung des betroffenen Dokuments aus – nicht des gesamten Katalogs.

Relevanz-Tuning für technische Produkte

Im B2B suchen Einkäufer anders als Endverbraucher. Sie suchen nach Artikelnummern, technischen Spezifikationen und Normen - nicht nach Produktnamen. Das Relevanz-Ranking muss diese Realität abbilden. Beispielsweise kann es sinnvoll sein, Artikelnummern und Herstellerbezeichnungen höher zu gewichten als Beschreibungstexte. Oder lagerverfügbare Produkte bevorzugt anzuzeigen. Oder Artikel, die der Kunde regelmäßig bestellt, automatisch weiter oben zu listen. Die konkrete Gewichtung ist immer projektspezifisch – entscheidend ist, dass bei technischen Produkten das Augenmerk auch auf technische Suchkriterien gelegt wird.

Schnell ausliefern, aktuell bleiben - gleichzeitig

Caching und Echtzeit-Daten stehen in einem natürlichen Spannungsfeld: Je aggressiver man cached, desto schneller die Antwortzeit - aber desto größer das Risiko veralteter Daten. Die Lösung liegt nicht in der Wahl zwischen beidem, sondern in einer intelligenten Kombination.

Die Caching-Strategie

• Schicht 1 - Edge/CDN: Statische Inhalte (Bilder, CSS, Produktbeschreibungen ohne Preis) werden am Rand des Netzwerks gecached - so nah wie möglich am Nutzer. Diese Inhalte werden praktisch verzögerungsfrei ausgeliefert, unabhängig vom Standort.

• Schicht 2 - Anwendungs-Cache (Redis): Häufig abgefragte, aber veränderliche Daten - Suchergebnisse, Kategorielisten, Facettenwerte - werden in einem schnellen Zwischenspeicher gehalten. Aktualisierung erfolgt ereignisbasiert: Ändert sich ein Produkt, wird genau dieser Cache-Eintrag ungültig - nicht der gesamte Cache.

• Schicht 3 - Vorberechnete Datenansichten: Komplexe Berechnungen, die sich selten ändern (Staffelpreise, Versandkostenmatrizen, Steuerberechnung), werden vorberechnet und als fertige Ergebnisse gespeichert. Der Anwendungsserver muss bei einer Anfrage nicht rechnen, sondern nur ablesen.

• Schicht 4 - Kundenspezifischer Micro-Cache: Für eingeloggte B2B-Kunden werden individuelle Preis- und Verfügbarkeitsdaten in einem kurzlebigen Cache gehalten (Lebensdauer: Sekunden bis Minuten). So wird das ERP nicht bei jedem Seitenaufruf belastet, aber die Daten bleiben aktuell genug für den Bestellprozess.

Ereignisbasierte Datenpipeline

Statt nachts den gesamten Katalog abzugleichen, erkennen wir Änderungen an der Quelle - in Echtzeit. Das Prinzip heißt Change Data Capture (CDC): Ein Agent beobachtet die Quelldatenbank (ERP, PIM, WMS) und erkennt jede Änderung automatisch. Diese Änderungen werden als Ereignisse über einen Nachrichtenverteiler (z. B. Apache Kafka) an alle angeschlossenen Systeme verteilt - Suchindex, Cache, Shop, Marktplatz.

Gezielte Cache-Invalidierung

Das Schwierigste am Caching ist nicht das Speichern - sondern das rechtzeitige Ungültigmachen. Ein Preis ändert sich im ERP: Welche Cache-Einträge sind betroffen? Der Produktcache, der Suchergebnis-Cache, der Warenkorb-Cache des Kunden, der CDN-Cache der Produktseite. Wir lösen das über ein Invalidierungs-Netzwerk: Jedes Änderungsereignis trägt die Information mit, welche Cache-Schlüssel betroffen sind. So wird nur das ungültig gemacht, was sich tatsächlich geändert hat - nicht der gesamte Cache.

Ergebnis: Produktseiten laden spürbar schneller. Preise und Bestände sind innerhalb von Sekunden nach einer Änderung aktuell. Der nächtliche Batch-Import entfällt - und damit das Risiko, dass Kunden mit veralteten Daten bestellen.

Deployments und Wartung ohne Betriebsunterbrechung

• B2B-Kunden bestellen während der Arbeitszeit: Anders als im Endkundengeschäft gibt es kein „ruhiges Zeitfenster" um 3 Uhr nachts. Bestellungen laufen von 7:00 bis 18:00, oft über Zeitzonen hinweg. Wartungsfenster sind ein Luxus, den man sich nicht leisten kann.

• Deployments ohne Unterbrechung: Neue Versionen werden über Blue-Green-Deployment oder Rolling Updates ausgerollt: Die neue Version läuft parallel zur alten. Traffic wird schrittweise umgeleitet. Bei Problemen: sofortige Rückkehr zur alten Version - ohne dass ein einziger Nutzer eine Fehlermeldung sieht.

• Datenbankmigration im laufenden Betrieb: Schemaänderungen an der Datenbank (neue Felder, geänderte Indizes) werden so gestaltet, dass alte und neue Anwendungsversion gleichzeitig funktionieren. Erst wenn die neue Version stabil läuft, werden die alten Strukturen aufgeräumt.

• Index-Neuaufbau ohne Ausfallzeit: Wenn der Suchindex komplett neu aufgebaut werden muss (z. B. nach einer Änderung der Datenstruktur), geschieht das in einen zweiten Index. Erst wenn der neue Index vollständig und validiert ist, wird nahtlos umgeschaltet.

Blue-Green-Deployment

Zwei identische Produktionsumgebungen - „Blue" und „Green" – laufen parallel. Eine bedient den Live-Traffic, die andere wird mit der neuen Version bestückt und getestet. Nach erfolgreicher Validierung wird der Load Balancer umgeschaltet: Green wird Live, Blue wird Standby. Rollback bedeutet: Einfach zurückschalten. Dauer: Sekunden.

Automatische Skalierung bei Lastspitzen

Montag 8:00 Uhr: Alle Einkäufer starten gleichzeitig. Die Last verdreifacht sich innerhalb von Minuten. Statt vertikal zu skalieren (größere Server) setzen wir auf horizontale Auto-Skalierung. Beispielsweise über AWS Auto Scaling Groups in Kombination mit Kubernetes, über Azure VMSS oder über vergleichbare Mechanismen in der Google Cloud. Das Prinzip: Containerisierte Anwendungen starten automatisch zusätzliche Instanzen, wenn definierte Schwellwerte überschritten werden - und fahren sie wieder herunter, wenn die Last sinkt. Die konkrete Umsetzung hängt von der bestehenden Infrastruktur ab - aber das Muster ist erprobt und skaliert zuverlässig.

Ausfallsicherheit: Was passiert, wenn ein System nicht erreichbar ist?

In einer Architektur mit vielen Komponenten wird irgendwann etwas ausfallen - das ist keine Frage des Ob, sondern des Wann. Wir designen für diesen Fall: Automatische Schutzschalter erkennen, wenn ein Service nicht mehr antwortet, und unterbrechen die Verbindung, bevor der Ausfall auf andere Systeme durchschlägt. Fallback-Mechanismen zeigen bei einem Suchindex-Ausfall Kategorielisten statt einer Fehlermeldung. Und Bestellungen werden in einer Warteschlange zwischengespeichert, wenn das ERP kurzzeitig nicht erreichbar ist.

Wo künstliche Intelligenz echten Unterschied macht

Automatisierte Datenaufbereitung

2 Millionen Produkte manuell pflegen ist unrealistisch. KI-Modelle erkennen Produktkategorien aus Rohtexten, ergänzen fehlende technische Attribute und normalisieren Einheiten (mm vs. cm, kg vs. g). Lieferantendaten in unterschiedlichen Formaten werden automatisch auf das interne Schema gemappt. Das PIM wird zur intelligenten Datenveredelung - und die Datenqualität verbessert sich kontinuierlich, statt mit der Katalogmenge zu erodieren.

Vorausschauendes Caching - Daten laden, bevor sie gebraucht werden

Statt auf Anfragen zu reagieren, antizipiert das System: Welche Produkte wird dieser Kunde wahrscheinlich als nächstes aufrufen? Basierend auf Bestellhistorie und Sitzungsverlauf werden Produktdaten und Preise vorgeladen - bevor der Nutzer klickt. Die Seite steht sofort bereit, weil die Daten bereits im Cache liegen.

Anomalieerkennung in Datenpipelines

Wenn ein Lieferant-Feed plötzlich 40 % weniger Produkte liefert oder alle Preise um den Faktor 100 steigen, muss das sofort auffallen - nicht erst nach dem Import. KI-basierte Anomalieerkennung überwacht eingehende Datenströme und stoppt fehlerhafte Importe, bevor sie den Produktkatalog beschädigen. Dazu: Benachrichtigung an das zuständige Team mit konkreter Ursachenanalyse.

Unser Ansatz: KI ist kein Ersatz für eine saubere Datenarchitektur - sie ist eine Ergänzung. Erst wenn die Grundlagen stimmen (einheitliche Datenquellen, ereignisbasierte Pipelines, saubere Indizes), entfaltet KI ihren vollen Nutzen. Wir bauen beides zusammen - Fundament und intelligente Schicht darüber.