Multi-Country Search-Infrastruktur: 60.000 SKUs über 18 Märkte managen

Wenn 18 Märkte auf einmal in dieselbe Suchzeile tippen

Viele Verantwortliche für internationale Shops fragen sich: Wie hält man eine Produktsuche über viele Märkte hinweg konsistent, wenn jeder Markt seine eigene Sprache, Währung, Preisliste und Verfügbarkeit hat? Die Antwort liegt in einer entkoppelten Such-Infrastruktur, die pro Markt eine eigene Sicht auf dasselbe Stammdaten-Set ausliefert, ohne dass die Antwortzeit zwischen den Ländern auseinanderläuft. Ein ganz normaler Dienstagvormittag im Betrieb macht greifbar, worum es dabei geht.

Ein internationaler B2B-Versandhändler aus dem DACH-Raum betreibt 18 lokalisierte Shops für Deutschland, Österreich, die Schweiz, Frankreich, Belgien, die Niederlande, Italien, Spanien, Portugal, Polen, Tschechien, Slowakei, Ungarn, Schweden, Dänemark, Norwegen, Finnland und die Vereinigten Arabischen Emirate. 60.000 Stammprodukte im PIM. In jedem Markt eine eigene Sprache, eine eigene Währung, ein eigener Sortimentsausschnitt, eine eigene Preisliste, ein eigener Lagerbestand pro Distribution Center, ein eigener Steuersatz, oft eine eigene Kategorisierungslogik. An einem normalen Dienstag um 10:47 Uhr läuft eine Suche aus Lyon auf "presse hydraulique 50 tonnes" parallel zu einer Suche aus München auf "Hydraulikpresse 50t" parallel zu einer Suche aus Dubai auf "مكبس هيدروليكي" parallel zu siebzehn anderen Anfragen aus siebzehn anderen Märkten. Jede dieser Suchen erwartet ihr lokales Sortiment, ihre lokale Verfügbarkeit, ihren lokalen Preis und eine Antwortzeit unter 200 Millisekunden.

Das ist Multi-Country-Search in der Realität. Ein einzelner Cluster muss 18 sprachlich, sortimentell, preislich und verfügbarkeitstechnisch getrennte Sichten auf dasselbe Stammdaten-Set ausliefern, ohne dass die Antwortzeit über die Märkte hinweg auseinanderläuft. Die Aufgabe ist um eine Größenordnung komplexer als ein nationaler Shop mit 60.000 SKUs, weil die Komplexität nicht linear, sondern multiplikativ wächst. Jeder neue Markt bringt neue Sprachregeln, neue Pflege-Pipelines, neue Lager-Schnittstellen, neue Performance-Anforderungen.

Dieser Artikel beschreibt, wie eine multi-country e-commerce suche technisch und organisatorisch aufgebaut werden muss, damit sie 60.000 SKUs über 18 Märkte konsistent durchsuchbar hält. Er zeigt, warum monolithische Such-Cluster bei dieser Größe an Performance-Grenzen stoßen. Er erklärt die Tradeoffs zwischen einem zentralen Index mit Markt-Filter und einer Multi-Index-Architektur mit einem Index pro Markt. Er geht auf die sprachlichen Eigenheiten der Tokenizer und Analyzer ein. Er beschreibt, wie lokale Lagerbestände, Währungen und Steuersätze in die Indexstruktur kommen. Er behandelt das Cross-Border-Spillover-Muster, wenn ein Markt aus dem Lager eines anderen Marktes beliefert wird. Und er ordnet ein, an welcher Stelle eine entkoppelte Multi-Tenant-Infrastruktur den Komplexitätsdruck vom Shop-Backend nimmt.

Was Multi-Country Search wirklich heißt

Was bedeutet Multi-Country-Search im operativen Betrieb wirklich und nicht nur in der Marketing-Broschüre?

Multi-Country wird in Marketing-Materialien oft als "Shop in mehreren Ländern verfügbar" verkauft. Operativ bedeutet es etwas anderes. Es bedeutet, dass die Such-Infrastruktur für jeden Markt eine eigene Antwort auf dieselbe Stammdaten-Frage liefert. Dieselbe SKU ist in Deutschland in Lager 1 verfügbar zum Preis A inklusive deutscher Mehrwertsteuer mit deutschem Produktnamen und deutscher Compound-Tokenisierung. Dieselbe SKU ist in Italien in Lager 2 verfügbar zum Preis B inklusive italienischer Mehrwertsteuer mit italienischem Produktnamen und italienischer Akzent-Normalisierung. Dieselbe SKU ist in den Vereinigten Arabischen Emiraten nicht verfügbar, weil der Export-Status der SKU dort regulatorisch nicht freigegeben ist.

Sechs Dimensionen sind pro Markt unterschiedlich.

Erstens die Sprache. Die Produktbezeichnungen, Beschreibungen, Attribut-Werte und Synonym-Listen sind pro Markt lokalisiert. Eine deutsche Hydraulikpresse heißt in Frankreich "presse hydraulique", in Italien "pressa idraulica", in Spanien "prensa hidráulica", in den Vereinigten Arabischen Emiraten "مكبس هيدروليكي". Die Tokenizer-Logik der Suche muss pro Markt die richtige Sprach-Variante laden. Eine deutsche Compound-Decompounding-Regel auf einem italienischen Produktnamen produziert Mülltreffer.

Zweitens die Währung. Preise sind in Euro, Schweizer Franken, polnischen Złoty, schwedischen Kronen, norwegischen Kronen, dänischen Kronen, tschechischen Kronen, ungarischen Forint, Vereinigte-Arabische-Emirate-Dirham geführt. Die Such-Infrastruktur muss pro Markt den richtigen Preis für die Anzeige im Trefferlisten-Frontend, für die Preisfilter und für die Sortier-Logik (Preis aufsteigend, Preis absteigend) bereitstellen.

Drittens das Sortiment. Nicht jede SKU ist in jedem Markt verfügbar. Ein elektrisches Gerät mit DE-Stecker ist in Italien sortimentell ausgeschlossen, ein bestimmter Industrie-Klebstoff ist in den Vereinigten Arabischen Emiraten regulatorisch verboten, eine bestimmte Schmuck-Linie ist in Frankreich exklusiv vertrieben. Die Sortimentsfilter-Logik gehört pro Markt sauber im Index abgebildet.

Viertens der Lagerbestand. Selbst wenn eine SKU sortimentell freigegeben ist, ist sie nicht in jedem Markt physisch verfügbar. Ein Verbrauchsmaterial liegt in Deutschland in drei Lagerorten, in Italien in einem, in den Vereinigten Arabischen Emiraten in keinem (Cross-Border-Bezug aus DE). Lagerbestände schwanken stündlich, sind aber Voraussetzung dafür, dass die Suche keine unbestellbaren Artikel ganz vorne im Listing zeigt.

Fünftens die Steuersätze. Endkunden-Preise unterscheiden sich pro Markt durch Mehrwertsteuer und länderspezifische Verbrauchssteuern. Wenn der Shop Brutto-Preise zeigt, müssen die Preise vor der Trefferliste pro Markt berechnet werden, entweder im Index gespeichert oder in der Query-Layer-Schicht berechnet.

Sechstens die Kategorisierung. Ein Produkt, das in Deutschland in die Kategorie "Hydraulik / Industriepressen" gehört, gehört in Italien vielleicht in die Kategorie "Macchinari Pesanti / Presse Industriali". Die Kategoriebaum-Struktur ist nicht eins zu eins übertragbar, weil sich die Sortimentsbreite pro Markt unterscheidet. Die Suche muss die markt-spezifische Kategorisierung als Filter unterstützen.

Diese sechs Dimensionen zusammen ergeben die echte Komplexität von Multi-Country-Search. Wer eine internationale Shop-Suche baut, baut nicht eine einzige Suche, sondern 18 eng verbundene Suchen, die auf dasselbe PIM und ERP zugreifen, aber pro Markt eine eigene Tokenisierungs-, Filter-, Preis-, Sortimentsund Kategorisierungslogik benötigen.

Warum monolithische Cluster bei 60.000 × 18 an Performance-Limits stoßen

Ab wann wird ein einzelner, monolithischer Such-Index für 60.000 SKUs über 18 Märkte zum Performance-Problem?

Die naive Architektur für eine internationale Suche speichert alle Märkte in einem einzigen Such-Index. 60.000 SKUs × 18 Sprachvarianten ergibt 1.080.000 Index-Dokumente, weil jedes Produkt pro Markt einmal als Dokument abgelegt wird. Plus 18 separate Lager-Felder pro Dokument, plus 18 separate Preisfelder, plus 18 separate Sortiments-Flags. Pro Dokument schnell 200 oder 300 Felder. Das ergibt einen Such-Index mit Hunderten von Millionen Feld-Instanzen.

Auf einem klassischen monolithischen Elasticsearch- oder Solr-Cluster läuft eine solche Index-Struktur theoretisch. Praktisch entstehen drei Probleme.

Erstens leidet die Query-Performance. Eine Suche aus dem deutschen Shop filtert auf das DE-Sortiment, lädt das DE-Preisfeld, wendet den DE-Analyzer an, sortiert nach DE-Lagerbestand. Der Query-Planner muss in jedem Dokument zuerst feststellen, welche der 18 Sortiments-Flags relevant ist, bevor er die Relevanz-Berechnung anstößt. Wenn die Filter-Klausel nicht früh genug greift, bewertet die Suche unnötig viele Dokumente. Bei einem realistischen Such-Volumen von ein paar hundert Queries pro Sekunde verteilt über die 18 Märkte sinkt die durchschnittliche Antwortzeit unter Last in Bereiche, in denen die 200-Millisekunden-Schwelle nicht mehr gehalten werden kann.

Zweitens leidet die Cache-Effizienz. Der Cluster-Cache hält Query-Ergebnisse pro Such-Anfrage. Ein DE-User und ein IT-User suchen denselben Begriff, aber das Ergebnis ist unterschiedlich, weil das Sortiment, der Preis und die Sprache anders sind. Der Cache speichert beide Ergebnisse separat. Die Cache-Hit-Rate sinkt mit der Anzahl der Märkte, weil sich die Query-Signatur pro Markt unterscheidet. Bei 18 Märkten halbiert sich die effektive Cache-Effizienz im Vergleich zu einem nationalen Shop, weil derselbe Cache-Speicher 18-fach geteilt werden muss.

Drittens leidet die Wartbarkeit. Eine Sortimentsänderung im polnischen Markt erfordert ein Update an allen 60.000 Stammprodukten im Index, weil das polnische Sortiments-Flag pro Dokument neu gesetzt werden muss. Eine Sprach-Analyzer-Verbesserung für Französisch zwingt zum Re-Indexing aller Dokumente, weil sich die Tokenisierung ändert. Die Update-Pipelines werden eng gekoppelt: ein Fehler in einem Markt blockiert die Index-Aktualisierung für alle anderen Märkte.

Diese Probleme sind kein theoretisches Risiko, sondern operative Realität. In Audits bei E-Commerce-Plattformen mit fünfzigtausend bis hunderttausend SKUs und zehn bis zwanzig Märkten sehen wir wiederkehrend, dass die Such-Antwortzeiten unter Last über die 200-Millisekunden-Schwelle steigen und dass die Index-Update-Pipelines an einzelnen Märkten hängenbleiben, ohne dass die anderen Märkte aktualisiert werden können. Die Suche ist dann nicht "kaputt", aber sie liefert ein langsameres und veraltetes Erlebnis als die Kategorieseite, und genau dort beginnt der Vertrauensverlust beim Endkunden.

Multi-Index vs Single-Index mit Markt-Filter

Sollte man pro Markt einen eigenen Such-Index anlegen oder alle Märkte in einem zentralen Index mit Markt-Filter halten?

Die Architektur-Entscheidung für eine Multi-Country-Suche dreht sich um die Frage, ob pro Markt ein eigener Such-Index angelegt wird oder ob ein zentraler Index mit Markt-Filter genutzt wird. Beide Strategien haben unterschiedliche Tradeoffs.

Die Multi-Index-Architektur legt pro Markt einen eigenen Such-Index an. Ein DE-Index, ein FR-Index, ein IT-Index, ein UAE-Index und so weiter. Jeder Index enthält nur die Dokumente, die in seinem Markt relevant sind, mit den markt-spezifischen Sprach-Analyzern, dem markt-spezifischen Preis, dem markt-spezifischen Lagerbestand. Die Vorteile sind operativ erheblich. Eine Sortimentsänderung in Polen betrifft nur den PL-Index. Eine Sprach-Analyzer-Verbesserung für Französisch betrifft nur den FR-Index. Eine Re-Indexing-Pipeline pro Markt kann unabhängig laufen. Die Query-Performance ist besser, weil der Query-Planner nur den markt-eigenen Index abfragt, ohne Filter über Sortiments-Flags. Die Cache-Effizienz ist höher, weil pro Markt ein eigener Cache-Bereich existiert. Der Nachteil ist die Maintenance-Overhead: 18 separate Indizes erfordern 18-fache Konfigurations-Pflege, 18-fache Monitoring-Dashboards, 18-fache Backup-Pipelines.

Die Single-Index-Architektur mit Markt-Filter hält alle Märkte in einem zentralen Index. Pro Dokument werden alle markt-relevanten Felder gespeichert (DE-Preis, FR-Preis, IT-Preis und so weiter), und die Query filtert über ein market_filter-Feld. Der Vorteil ist die einfache Maintenance: ein Index, eine Konfiguration, ein Backup-Pipeline. Der Nachteil ist die Query-Performance unter Last und die geringere Cache-Effizienz, wie im vorigen Abschnitt beschrieben.

Eine dritte Option ist die hybride Architektur. Sie nutzt Multi-Index für die markt-spezifischen Such-Indizes und kombiniert sie mit einem zentralen Stammdaten-Index, der die nicht-markt-spezifischen Felder enthält (Bilder, Marken-Logos, technische Spezifikationen). Eine Suche fragt zuerst den markt-spezifischen Index ab, holt dann die Stammdaten aus dem zentralen Index. Die hybride Architektur kombiniert die Maintenance-Einfachheit eines zentralen Index für Stammdaten mit der Query-Performance und Cache-Effizienz separater Markt-Indizes.

Die Entscheidung hängt von zwei Faktoren ab. Erstens von der Marktgröße. Wenn alle 18 Märkte vergleichbares Such-Volumen erzeugen, ist Multi-Index klar überlegen, weil die Query-Last gleichmäßig über separate Indizes verteilt ist. Wenn 80 Prozent des Such-Volumens auf zwei Märkte entfallen und die anderen 16 Märkte vernachlässigbar sind, kann eine Single-Index-Architektur mit Markt-Filter operativ einfacher sein. Zweitens vom Sortimentsschnitt. Wenn die Sortimente zwischen den Märkten zu 80 Prozent überlappen, ist eine hybride Architektur die effizienteste. Wenn die Sortimente zu 80 Prozent disjunkt sind (jeder Markt hat sein eigenes Sortiment), ist Multi-Index die einzige sinnvolle Option.

In der Praxis sehen wir bei B2B-Plattformen mit großen Sortimenten und hohen Konsistenz-Anforderungen am häufigsten die hybride Architektur, weil sie die Vorteile beider Welten kombiniert. Wir haben den verwandten Punkt zur Konsistenz zwischen Kategorieseite und Suche in unserem Beitrag zu Gruppierungslogik in der Shop-Suche im Detail beschrieben. Multi-Country verschärft dieses Konsistenzproblem, weil die Gruppierungslogik pro Markt eine andere Sortimentssicht haben muss.

Sprach-spezifische Tokenizer und Analyzer

Warum braucht jeder Markt einen eigenen Sprach-Analyzer, statt überall denselben Standard-Tokenizer zu verwenden?

Die Tokenisierung ist die unsichtbarste, aber folgenreichste Stellschraube in einer mehrsprachigen Suche. Jede Sprache hat eigene Regeln, wie Wörter zerlegt und normalisiert werden, bevor die Suche sie indiziert. Eine deutsche Compound-Decompounding-Regel zerlegt "Hydraulikpressenölfilter" in "Hydraulik", "Pressen", "Öl", "Filter" und ermöglicht damit eine Treffer-Erkennung auch dann, wenn der Endkunde "Ölfilter Hydraulik" tippt. Eine französische Akzent-Normalisierung mappt "presse hydraulique" auf "presse hydraulique" und erkennt damit auch Tippfehler ohne Akzent. Eine arabische Tokenisierung respektiert die Right-to-Left-Schreibrichtung und die Buchstabenformen, die je nach Position im Wort unterschiedlich aussehen.

Sechs Sprach-Klassen sind in einer typischen 18-Märkte-Konstellation relevant.

Erstens die germanischen Sprachen mit Compound-Words. Deutsch, Niederländisch, Schwedisch, Dänisch, Norwegisch bilden zusammengesetzte Substantive ohne Trennzeichen. "Hydraulikpresse", "hydrauliek pers", "hydraulpress". Die Tokenizer-Logik braucht ein Compound-Decompounding-Wörterbuch pro Sprache, das die Compound-Words in ihre Bestandteile zerlegt. Wir haben die Mechanik der Compound-Decompounding in unserem Beitrag zu Tokenseparatoren in der Shop-Suche ausführlich behandelt. In einer Multi-Country-Konstellation gilt dieselbe Mechanik pro germanischer Sprache mit eigenem Wörterbuch.

Zweitens die romanischen Sprachen mit Akzenten. Französisch, Italienisch, Spanisch, Portugiesisch nutzen Akzente und Diakritika. "café", "naïf", "señor", "ação". Endkunden tippen häufig ohne Akzente. Die Tokenizer-Logik braucht eine Akzent-Normalisierung, die "cafe" auf "café" mappt, ohne die ursprüngliche Schreibung zu verlieren. Zusätzlich helfen Stemming-Regeln für die Pluralformen und Konjugationen.

Drittens die slawischen Sprachen mit reicher Morphologie. Polnisch, Tschechisch, Slowakisch, Ungarisch haben eine ausgeprägte Beugung mit Fall-Endungen und Geschlechts-Markierungen. "stół" (Tisch nominativ), "stołu" (Tisch genitiv), "stołem" (Tisch instrumental). Die Tokenizer-Logik braucht ein Stemming, das die verschiedenen Wortformen auf eine gemeinsame Stammform reduziert. Ohne Stemming finden Kunden Produkte nur, wenn sie die exakte Nominativ-Form tippen.

Viertens die finno-ugrischen Sprachen mit agglutinierender Morphologie. Finnisch und Ungarisch hängen mehrere Suffixe an dasselbe Wort. Ein finnisches Wort wie "talossanikin" enthält die Bedeutung "auch in meinem Haus" in einem einzigen Token. Die Tokenizer-Logik braucht eine Suffix-Erkennung, die die agglutinierten Bestandteile separiert.

Fünftens die semitischen Sprachen mit Right-to-Left-Schreibrichtung und konsonantischer Wurzel-Morphologie. Arabisch im UAE-Markt bildet Wörter über drei oder vier Konsonanten-Wurzeln plus Vokal-Muster. Die Tokenizer-Logik braucht eine Wurzel-Extraktion plus eine Behandlung der diakritischen Vokal-Zeichen (Tashkil), die in geschriebenem Arabisch meist weggelassen werden.

Sechstens die Sprachen mit Sonderzeichen-Behandlung. Die schwedische, dänische und norwegische Schreibung nutzt Sonderzeichen wie å, ä, ö, ø, æ. Die Tokenizer-Logik muss diese als eigenständige Buchstaben behandeln und nicht als Akzent-Variante von a, o (eine häufige Fehlkonfiguration aus dem amerikanischen Setup-Default).

In einer Multi-Index-Architektur wird pro Markt der passende Sprach-Analyzer konfiguriert. In einer Single-Index-Architektur müssen die Analyzer pro Feld konfiguriert werden. In beiden Fällen ist die Konfigurations-Pflege erheblich, weil pro Sprache nicht nur der Analyzer ausgewählt, sondern auch die Synonym-Liste, die Stopp-Wort-Liste, die Compound-Decompounding-Wörterbücher und die markt-spezifischen Eigenheiten gepflegt werden müssen. Wer hier mit Standard-Konfigurationen arbeitet, bekommt eine Suche, die in den dominanten Märkten (DE, FR, EN) ausreichend funktioniert und in den Randmärkten (UAE, FI, HU) systematisch schlechtere Treffer liefert.

Lokale Lagerbestände als Filter im Index

Wie verhindert man, dass nicht lieferbare Produkte ganz oben in der Trefferliste eines Marktes landen?

Die zweite große Herausforderung neben der Sprache ist der Lagerbestand. Eine SKU kann sortimentell in 18 Märkten verfügbar sein, aber physisch nur in 9 Märkten am Lager liegen. Die Lagerbestände schwanken stündlich. Die Suche muss in der Trefferliste die nicht-lagernden SKUs nach unten priorisieren oder ganz herausfiltern, weil ein nicht-lieferbares Produkt auf der ersten Trefferseite die Conversion-Rate brutal senkt.

Drei Mechaniken müssen sauber zusammenspielen.

Erstens die markt-spezifische Lagerbestand-Indexierung. Pro Dokument und pro Markt wird ein Lagerbestand-Wert im Index gespeichert, idealerweise als Integer (Stückzahl) oder als Enum (in_stock, low_stock, out_of_stock). Bei 18 Märkten ergibt das 18 Lagerbestand-Felder pro Dokument plus die nötigen Aggregations-Felder (total_stock_all_markets, primary_warehouse_stock).

Zweitens die Live-Sync-Pipeline aus dem ERP. Lagerbestände schwanken im Minuten- bis Stunden-Takt. Die Suche braucht eine Live-Sync-Pipeline, die Bestandsänderungen aus dem ERP in den Such-Index pushed, idealerweise unter einer Minute. Polling-basierte Pipelines (alle 15 Minuten den kompletten Bestand neu laden) sind operativ einfach, aber sie produzieren Lag und Last. Event-basierte Pipelines (jeder ERP-Bestand-Change feuert ein Event, das den Such-Index aktualisiert) sind operativ aufwendiger, aber sie sind die einzige saubere Lösung für Märkte mit hoher Lagerbestand-Volatilität.

Drittens die Filter-Logik in der Trefferliste. Die Suche darf nicht-lagernde Produkte nicht einfach ignorieren, weil das den Kunden vor leere Trefferlisten stellt. Stattdessen sortiert sie nach Lagerstatus: zuerst die in_stock-Produkte, dann die low_stock-Produkte, am Ende die out_of_stock-Produkte mit einem deutlichen Hinweis "Bald wieder verfügbar". So sieht der Kunde, dass die Suche das Produkt kennt, aber er erkennt sofort, dass er es nicht sofort kaufen kann.

In Multi-Country-Konstellationen kommt eine vierte Mechanik hinzu, die wir gleich im Cross-Border-Abschnitt vertiefen. Wenn ein Markt aus einem anderen Markt beliefert wird (z. B. UAE bezieht aus DE), muss die Suche die Lagerbestände beider Märkte korrelieren. Ein in UAE nicht lagerndes Produkt kann trotzdem als verfügbar gezeigt werden, wenn DE-Lager vorhanden und der Cross-Border-Versand für die SKU freigegeben ist.

Eine Geschäftsführung beschreibt den operativen Effekt einer konsistenten Lagerbestand-Logik in der Suche so:

"BatteryIncluded.ai ist genau das, was man sich von moderner E-Commerce-Technologie wünscht: blitzschnelle Suche auch bei über 50.000 Produkten, volle Anpassbarkeit für komplexe Anforderungen, und ein Support, der nicht nur reagiert, sondern wirklich versteht. Stabil, skalierbar, zukunftssicher."

Österreichischer Bundesverlag (ÖBV)

Die Kombination aus Stabilität und Skalierbarkeit ist genau die Voraussetzung, unter der die Live-Lagerbestand-Sync-Pipeline auch bei 18 Märkten und stündlich schwankenden Beständen zuverlässig läuft.

Currency- und Tax-Awareness: Preise im Index oder zur Query-Time

Gehören markt-spezifische Preise, Währungen und Steuersätze fest in den Index oder werden sie erst zur Query-Time berechnet?

Die dritte Dimension nach Sprache und Lagerbestand ist der Preis. Preise unterscheiden sich pro Markt durch die Listen-Kalkulation (Preise pro Markt im PIM gepflegt), die Währung (Umrechnung oder eigene Kalkulation), die Steuersätze (Mehrwertsteuer, Verbrauchssteuer), die Rabatt-Stufen (Mengenrabatt, B2B-Konditionen, Aktions-Preise) und die Anzeige-Logik (Netto in B2B, Brutto in B2C).

Zwei Architektur-Entscheidungen sind zu treffen.

Erstens: werden die Preise im Such-Index gespeichert oder zur Query-Time berechnet?

Wenn die Preise im Index gespeichert werden, muss pro Markt und Produkt ein Preis-Feld existieren. Das vergrößert den Index, aber es macht die Preis-Filter und Preis-Sortierung schnell. Eine Suche aus Italien mit Filter "Preis bis 500 Euro" greift direkt auf das IT-Preis-Feld. Die Latenz ist niedrig, die Cache-Effizienz hoch.

Wenn die Preise zur Query-Time berechnet werden, ist der Index schlanker, aber die Such-Schicht muss pro Treffer eine Preis-Berechnung durchführen, die das markt-spezifische Listen-Preis, die Steuersätze und die Rabatt-Stufen einbezieht. Die Latenz wird höher, die Cache-Effizienz niedriger. Der Vorteil ist die Aktualität: Preisänderungen brauchen kein Index-Update.

Die Praxis-Antwort ist eine Mischung. Listen-Preise werden im Index gespeichert (relativ stabil, ändern sich pro Quartal oder bei Aktions-Phasen). Aktions-Preise werden ebenfalls im Index gespeichert, aber mit einem Gültigkeits-Zeitstempel. Personalisierte Konditionen (B2B-Kunden-Rabatte) werden zur Query-Time berechnet, weil sie kunden-individuell sind. Brutto-Preise werden aus den Netto-Preisen plus markt-spezifischem Steuersatz berechnet, entweder bei der Indexierung oder zur Query-Time je nach Last-Profil.

Zweitens: wie werden die Filter und Sortier-Logiken aufgesetzt?

Die Preis-Filter und Preis-Sortier-Logik müssen pro Markt das richtige Preis-Feld nutzen. Eine Suche aus Schweden filtert "Preis bis 5000 Kronen", eine Suche aus Deutschland filtert "Preis bis 500 Euro". Die Trefferliste sortiert nach DE-Preis oder nach SE-Preis. Die Such-Schicht muss markt-aware sein und die richtige Preisspalte adressieren. In einer Multi-Index-Architektur ist das trivial, weil pro Markt nur ein Preis-Feld existiert. In einer Single-Index-Architektur müssen die Query-Templates pro Markt das richtige Preis-Feld auswählen.

Die Steuer-Logik gehört in dieselbe Schicht. Pro Markt ein Mehrwertsteuer-Satz, plus eventuelle Verbrauchssteuern (z. B. französische Eco-Tax auf bestimmte Produkte, deutsche Energieabgabe). Die Brutto-Preis-Anzeige ist Voraussetzung für die Compliance in B2C-Shops und gehört in die Such-Architektur eingebaut, nicht in das Frontend ausgelagert.

Cross-Border-Spillover: User in AT sucht, wir zeigen DE-Stock

Was passiert, wenn ein Produkt im lokalen Lager fehlt, aber aus dem Lager eines anderen Marktes lieferbar wäre?

Eine spezielle Multi-Country-Mechanik ist der Cross-Border-Spillover. Wenn ein Markt aus dem Lager eines anderen Marktes beliefert wird, weil das lokale Lager kein Bestand hat, soll die Suche das anzeigen können. Beispiel: ein User in Österreich sucht ein Produkt, das im AT-Lager nicht vorrätig ist, aber im DE-Lager mit Cross-Border-Versand verfügbar wäre. Die Suche soll das Produkt nicht ausblenden, sondern es mit einem Cross-Border-Hinweis und einer angepassten Lieferzeit-Angabe zeigen.

Der Mechanismus ist konzeptionell einfach, operativ aber heikel. Drei Bedingungen müssen erfüllt sein, damit ein Cross-Border-Treffer angezeigt werden darf.

Erstens muss die SKU im Quell-Markt verfügbar sein. Das AT-Sortiments-Flag ist auf 0, das DE-Sortiments-Flag auf 1 und der DE-Lagerbestand größer 0.

Zweitens muss die SKU für Cross-Border-Versand freigegeben sein. Manche Produkte sind regulatorisch nicht aus Deutschland nach Österreich versendbar (z. B. bestimmte Chemikalien, deutsche-spezifische Sicherheits-Zertifizierungen). Die Cross-Border-Freigabe gehört als eigenes Feld ins PIM.

Drittens müssen die Cross-Border-Konditionen (Lieferzeit, Versandkosten, Steuer-Berechnung) für den Ziel-Markt bekannt sein. Eine Lieferung aus dem DE-Lager nach Österreich dauert typisch zwei bis drei Tage statt einem Tag. Die Versandkosten sind höher. Die Mehrwertsteuer wird je nach Konstellation entweder mit DE- oder mit AT-Satz berechnet. Diese Konditionen müssen für die Treffer-Anzeige zur Verfügung stehen, damit der Kunde keine Überraschung im Checkout erlebt.

Die Such-Architektur bildet diese Mechanik typischerweise als zweistufige Abfrage ab. Der erste Schritt fragt den AT-Index ab. Wenn weniger als eine Mindestanzahl Treffer (z. B. zehn) zurückkommt, wird der DE-Index nach denselben Begriffen abgefragt, gefiltert auf SKUs mit Cross-Border-AT-Freigabe. Die Cross-Border-Treffer werden mit einem Hinweis "Aus deutschem Lager, Lieferung in 2 bis 3 Werktagen" markiert. Der Endkunde sieht eine vollständigere Trefferliste, der Shop spart Verkaufschancen, die sonst durch sortimentslose AT-Treffer verloren gingen.

In B2B-Plattformen mit großen Sortimenten ist die Cross-Border-Mechanik oft der entscheidende Conversion-Hebel für die Randmärkte, weil die lokalen Sortimente dort nicht die volle Sortimentsbreite abdecken. Eine Geschäftsführung im DACH-Großhandel beschreibt den Effekt so:

"Die Produktsuche ist kein Extra, sie ist der erste Kontakt mit unseren Kund:innen. Mit BatteryIncluded haben wir bei Wurm die Kontrolle zurückgewonnen: bessere Relevanz, weniger Pflege, mehr Wirkung. Jetzt kann der Vertrieb die Suche ohne IT steuern, Marketingaktionen greifen durch und der Shop wirkt wie aus einem Guss. Eine strategisch richtige Entscheidung."

G. Wurm GmbH + Co. KG

Die Aussage "der Shop wirkt wie aus einem Guss" ist genau das, was Cross-Border-Spillover für Multi-Country-Shops leisten muss. Der Endkunde soll nicht zwischen lokal verfügbar und international verfügbar unterscheiden müssen. Er soll alle relevanten Produkte sehen und über die Lieferzeit-Angabe selbst entscheiden, ob die längere Lieferzeit für ihn akzeptabel ist.

Latency-Budget pro Markt: 200ms Pflicht auch regional verteilt

Wie hält man die 200-Millisekunden-Schwelle auch in weit entfernten Märkten wie den Vereinigten Arabischen Emiraten oder Finnland?

Die 200-Millisekunden-Schwelle gilt pro Markt und unabhängig davon, wo der Such-Cluster physisch steht. Ein Cluster in Frankfurt liefert eine Suche aus München in 200 Millisekunden. Aus Dubai dauert die Anfrage allein durch die Netz-Latenz zwischen UAE und Frankfurt etwa 120 bis 150 Millisekunden, bevor der Server überhaupt mit der Bearbeitung anfängt. Damit bleibt dem Server selbst nur 50 bis 80 Millisekunden Zeit für die Such-Berechnung, was technisch unrealistisch ist.

Drei Architektur-Antworten sind etabliert.

Erstens die regional verteilten Cluster. Der Such-Cluster wird in mehreren Regionen betrieben (z. B. Frankfurt für EU, Dubai für MENA). Die Anfragen werden geo-geroutet auf den nächstgelegenen Cluster. Die Netz-Latenz wird auf ein paar Dutzend Millisekunden gedrückt, der Server-Antwort-Anteil bleibt im Budget. Die Architektur ist betrieblich aufwendig, weil pro Region ein Cluster gepflegt, monitort und mit den ERP- und PIM-Updates synchronisiert werden muss.

Zweitens das Edge-Caching für statische Treffer-Vorschläge. Vorgeschlagene Trending-Treffer und statische Filter-Vorschläge (Top-Kategorien, populäre Marken) werden auf CDN-Edge-Knoten gecached. Sie werden direkt vom Edge-Knoten ausgeliefert, ohne den Such-Cluster zu kontaktieren. Damit wird die Wahrnehmung von Geschwindigkeit verbessert, auch wenn die eigentliche Such-Berechnung weiter im zentralen Cluster läuft.

Drittens das Pre-Loading der ersten Trefferseite. Sobald der Endkunde mit dem Tippen anfängt, wird im Hintergrund die wahrscheinlichste Suche vorausberechnet. Wenn die Tipp-Vorhersage trifft, ist die Trefferliste bereits geladen, bevor der Endkunde die Enter-Taste drückt. Die Mechanik haben wir im Kontext der Autocomplete-Logik in unserem Beitrag zu Autocomplete-Vorschlägen mit Conversion-Wirkung ausführlicher beschrieben. In Multi-Country-Konstellationen ist sie besonders wertvoll, weil sie die Wahrnehmung von Geschwindigkeit über Märkte mit hoher Netz-Latenz hebt.

Die Latenz-Frage ist eine Architektur-Entscheidung, nicht eine Tuning-Aufgabe. Wer mit einem einzigen zentralen Cluster startet und erst bei steigender Last regional verteilt, hat eine längere Migrations-Phase vor sich, in der die Performance-Beschwerden aus den entfernten Märkten kontinuierlich steigen. Wer von Anfang an regional plant, baut die Pipelines und Monitoring-Systeme so auf, dass die Skalierung auf neue Regionen mit überschaubarem Aufwand möglich ist. Die Mechanik der Such-Performance unter Last haben wir auch im Kontext der Tippfehler- und Fehlertoleranz-Logik in unserem Beitrag zu Fehlertoleranz in der Shop-Suche berührt.

ERP- und PIM-Sync: 18-fach orchestrierte Update-Pipelines

Was ist die operativ anspruchsvollste Seite einer Multi-Country-Suche, wenn nicht die reine Query-Performance?

Die operativ anspruchsvollste Seite der Multi-Country-Suche ist nicht die Query-Performance, sondern die Daten-Sync-Pipeline. Pro Markt müssen mehrere Daten-Quellen orchestriert werden. Stammdaten aus dem PIM (Produktnamen, Beschreibungen, Bilder, Kategorien). Bewegungsdaten aus dem ERP (Lagerbestände, Preise, Sortiments-Flags, Cross-Border-Freigaben). Lokalisierungs-Daten aus dem TMS (Translation Management System) für die markt-spezifischen Sprachvarianten. Marketing-Daten aus dem CMS für die Aktions-Preise und Kampagnen-Boosts.

Jede dieser Quellen hat eine eigene Update-Frequenz und ein eigenes Liefer-Format. Stammdaten werden typisch täglich aktualisiert, Bewegungsdaten in Minuten- bis Stunden-Takten, Lokalisierungen pro Übersetzungs-Sprint (wöchentlich oder monatlich), Marketing-Daten pro Kampagnen-Start (unregelmäßig). Bei 18 Märkten und vier Quellen pro Markt ergibt das 72 mögliche Sync-Pipelines.

Drei Architektur-Pattern haben sich in der Praxis durchgesetzt.

Erstens die zentrale Daten-Drehscheibe. Alle Quellen (PIM, ERP, TMS, CMS) speisen in einen zentralen Stream-Layer (etwa Kafka oder ein anderer Event-Bus). Der Stream-Layer verteilt die Events markt-spezifisch in die Such-Indizes. Der Vorteil ist die saubere Entkopplung der Quellen vom Such-Cluster. Der Nachteil ist die zusätzliche Infrastruktur-Komplexität.

Zweitens die markt-spezifischen Sync-Worker. Pro Markt läuft ein eigener Sync-Worker, der die relevanten Quellen aktiv pollt oder Event-Streams konsumiert und die markt-spezifischen Updates in den Such-Index pushed. Der Vorteil ist die operative Robustheit: ein Fehler in einem Markt-Worker blockiert nicht die anderen Märkte. Der Nachteil ist die 18-fach gepflegte Worker-Konfiguration.

Drittens die Backfill-Pipelines für Schema-Migrationen. Wenn das Index-Schema sich ändert (z. B. ein neues Feld für eine neue Steuer-Logik), muss der gesamte Index pro Markt neu aufgebaut werden. Backfill-Pipelines laden die Stammdaten und Bewegungsdaten aus den Quellen, transformieren sie und schreiben sie in den neuen Index. Bei 60.000 SKUs × 18 Märkten ist ein Backfill eine mehrstündige Operation, die ohne Beeinträchtigung des Live-Such-Betriebs laufen muss. Die etablierte Lösung ist eine Blue-Green-Architektur: der neue Index wird parallel zum alten Index befüllt, dann wird per Alias-Switch live geschaltet.

Die Komplexität der Sync-Pipelines ist der Hauptgrund, warum viele Shops Multi-Country-Search nicht selbst aufbauen, sondern eine spezialisierte Infrastruktur einkaufen. Die nötige Konfigurations- und Monitoring-Disziplin übersteigt die Kapazität typischer E-Commerce-Teams. Wir gehen auf die Mechanik der ERP-Live-Daten-Synchronisation in einem späteren Beitrag der Reihe vertieft ein, dort liegt der Schwerpunkt auf der Frage, wie Live-ERP-Daten in der Trefferliste als Filter genutzt werden können, ohne dass das Shop-Backend zur Datenbank-Last wird.

Multi-Tenant-Architektur als entkoppelte Such-Infrastruktur

Womit nimmt man dem Shop-Backend den gesamten Komplexitätsdruck aus 18 Märkten ab?

Die strategische Antwort auf die Multi-Country-Komplexität ist eine entkoppelte Infrastruktur, in der die Suche als eigenständiger Layer zwischen Shop-Frontend und ERP/PIM steht. Sie übernimmt die markt-spezifische Tokenisierung, die Lagerbestand-Sync, die Preis-Berechnung, die Cross-Border-Logik und die Latenz-Garantie. Das Shop-Backend liefert die Stammdaten und die Bewegungsdaten, ohne sich um die Such-Mechanik zu kümmern. Das Frontend stellt nur die Anfragen und rendert die Trefferliste.

In dieser Architektur ist die Such-Infrastruktur Multi-Tenant aufgebaut. Pro Markt existiert ein logischer Tenant mit eigenem Index, eigener Sprach-Konfiguration, eigenem Preis-Modell, eigenem Lagerbestand-Feed. Die Tenants teilen sich die Cluster-Infrastruktur, aber sie sind logisch isoliert. Ein Fehler in der Pflege eines Tenants betrifft die anderen Tenants nicht. Eine Last-Spitze in einem Tenant kann über Cluster-Autoscaling abgefangen werden, ohne die anderen Tenants zu beeinträchtigen.

Volt Search® von BatteryIncluded ist als solche Multi-Tenant-Infrastruktur konzipiert. Pro Markt wird ein eigener Search-Tenant aufgesetzt, mit markt-spezifischen Sprach-Analyzern, lokalen Lagerbestand-Feeds, lokaler Währung und Steuerlogik, lokaler Cross-Border-Mechanik. Die Tenant-Konfiguration wird im Admin-Backend gepflegt, ohne dass das Shop-Team Such-Cluster-Wissen benötigt. Die ERP- und PIM-Sync-Pipelines werden über standardisierte Konnektoren angebunden, die die typischen E-Commerce-Plattformen (Shopware, Magento, WooCommerce) sowie die häufigen ERP- und PIM-Systeme out of the box unterstützen.

Die operative Konsequenz für ein DACH-Unternehmen mit internationaler Ausrichtung ist, dass die Multi-Country-Suche kein internes Engineering-Projekt ist, sondern eine Konfigurations-Aufgabe. Eine neue Markt-Aktivierung dauert nicht Monate, sondern Wochen. Eine Sortimentsänderung in einem Markt wirkt sich nicht auf die Stabilität anderer Märkte aus. Eine Last-Spitze im Frühjahrs-Geschäft skaliert über die Multi-Tenant-Infrastruktur, ohne dass das Shop-Backend eingreifen muss.

Die Hybrid LLM Search ergänzt diese Architektur um eine semantische Schicht, die die markt-spezifischen Anfragen versteht, ohne pro Markt eine eigene Synonym-Liste zu benötigen. Eine Anfrage "presse hydraulique pour atelier" wird semantisch interpretiert (Suche nach einer Hydraulikpresse für Werkstatt-Einsatz), unabhängig davon, ob die Produktnamen im FR-Index "presse hydraulique" oder "presse à hydraulique" lauten. Die semantische Schicht reduziert den Pflege-Aufwand für die markt-spezifischen Synonym-Listen erheblich und macht die Suche auch in Randmärkten mit kleineren Sprach-Datensätzen brauchbar.

DSGVO-konforme KI und Cookieless im Multi-Country-Setup

Wie bleibt eine KI-Suche über EU, Schweiz und die Vereinigten Arabischen Emirate hinweg gleichzeitig datenschutzkonform?

Die DSGVO-Konformität ist im Multi-Country-Kontext zugleich rechtliche Pflicht und kommerzielles Argument. In der EU gelten die DSGVO-Regeln einheitlich, in den UAE existieren eigene Datenschutz-Vorgaben, in der Schweiz das revidierte Datenschutzgesetz. Eine Such-Infrastruktur, die personenbezogene Daten verarbeitet (User-IDs, Verhaltensprofile, geolokalisierte Profile), muss diese Vorgaben pro Markt einhalten.

Die einfachste Lösung ist, die Such-Infrastruktur ohne personenbezogene Daten zu betreiben. Die Suche arbeitet auf Produktdaten und auf den Query-Begriffen des aktuellen Suchvorgangs. Sie speichert keine User-IDs, baut keine Profile auf, trackt nicht über Sitzungen hinweg. Damit ist sie operativ cookieless und in allen Märkten gleichermaßen konform.

Die markt-spezifischen Such-Signale, die die Trefferliste über die Zeit verbessern (Klick-Verhalten auf Trefferkarten, Filter-Nutzung, Verweil-Dauer auf Trefferseiten), werden im AI Data Discovery Framework auf Aggregat-Ebene verarbeitet. Die Aggregate verbessern die Relevanz-Berechnung, ohne dass die Suche jemals individuelle Nutzer-Profile aufbaut. Diese Architektur löst das Multi-Country-DSGVO-Problem strukturell, weil die Frage "Wer wird wo wie getrackt?" gar nicht erst entsteht. Es wird niemand individuell getrackt, weder in DE noch in FR noch in UAE.

Im Vergleich zu klassischen US-basierten Anbietern, die auf Cookie- und Profil-basierter Personalisierung aufbauen, ist diese strukturelle DSGVO-Konformität ein Wettbewerbsvorteil. Made in Germany als Hosting-Standort verstärkt das Argument im DACH-Markt, DSGVO-konforme KI als Architektur-Prinzip verstärkt es in allen EU-Märkten.

Was Sie diese Woche tun können

Wo fängt man konkret an, wenn die Performance-Beschwerden aus den Randmärkten zunehmen?

Multi-Country-Search-Infrastruktur ist keine Projektphase, die nebenbei läuft. Sie ist eine Architektur-Entscheidung mit Konsequenzen für Sortimentspflege, Preis-Kalkulation, Lagerbestand-Sync, Sprach-Lokalisierung, Steuerlogik und Hosting-Strategie. Wenn Sie heute mit einer monolithischen Suche oder einer einfachen Plattform-Standard-Suche in mehreren Märkten arbeiten und die Performance-Beschwerden aus den Randmärkten zunehmen, ist die folgende Reihenfolge der pragmatischste Einstieg.

Schritt eins ist die Markt-Volumen-Analyse. Erheben Sie das tatsächliche Such-Volumen pro Markt aus den Analytics-Daten der letzten 90 Tage. Welche Märkte produzieren 80 Prozent des Such-Volumens? Welche Märkte sind sortimentstief, welche schlank? Welche Märkte haben die höchste Sprach-Komplexität (Compound-Words, Akzente, Right-to-Left)? Die Antworten bestimmen, ob Sie mit Single-Index, Multi-Index oder hybrider Architektur arbeiten.

Schritt zwei ist die Lagerbestand-Sync-Diagnose. Wie schnell schwanken Ihre Lagerbestände pro Markt? Welche Update-Frequenz braucht die Suche, damit out-of-stock-Produkte nicht ganz vorne auf der Trefferseite stehen? Welche Latenz produziert Ihre aktuelle Polling-Pipeline? Die Antworten bestimmen, ob Sie eine Polling- oder eine Event-basierte Live-Sync-Pipeline brauchen.

Schritt drei ist die Sprach-Konfigurations-Analyse. Welche Analyzer und Tokenizer laufen aktuell pro Markt? Sind sie sprach-spezifisch oder verwenden Sie überall den englischen Standard-Analyzer? Welche Synonym-Listen sind gepflegt, welche fehlen? Welche Compound-Decompounding-Wörterbücher sind aktiv? Die Antworten zeigen, in welchen Märkten Sie die Sprach-Logik nachschärfen müssen.

Schritt vier ist die Latenz-Messung pro Markt. Messen Sie die End-to-End-Antwortzeit der Suche aus den wichtigsten Märkten, idealerweise mit synthetischen Monitoring-Tools, die aus dem Zielland heraus messen. Wenn die Antwortzeit aus UAE oder FI über 400 Millisekunden liegt, brauchen Sie eine Cluster-Verteilung oder eine Edge-Caching-Strategie.

Schritt fünf ist die Cross-Border-Bestandsaufnahme. Welche Märkte werden aus welchen Lagern beliefert? Welche SKUs sind für Cross-Border-Versand freigegeben? Welche Cross-Border-Konditionen müssen für die Anzeige bekannt sein? Die Antworten zeigen, ob Sie Cross-Border-Spillover bereits in der Suche abbilden oder ob hier ein blinder Fleck mit Umsatz-Verlust besteht.

Schritt sechs ist der Pilot-Test. Wählen Sie einen Markt mittlerer Größe und mittlerer Komplexität (etwa Polen oder Spanien) und bauen Sie dort die Such-Architektur prototypisch nach Multi-Index-Pattern um. Messen Sie zwei Wochen lang Antwortzeit, Trefferqualität und Sortimentskonsistenz gegen die alte Lösung. Das ist Ihr A/B-Test für die Architektur-Investition. Wenn der Markt-Pilot überzeugt, rollen Sie die Architektur auf die anderen Märkte aus.

Diese sechs Schritte sind in jedem Fall sinnvoll, unabhängig davon, ob Sie später auf eine vollständige spezialisierte Multi-Country-Such-Infrastruktur wechseln oder Ihre vorhandene Suche optimieren. Was sie nicht ersetzen können, ist die operative Reife einer dedizierten Search-Plattform, die die markt-spezifischen Tenants out of the box konfigurierbar macht, die Live-ERP-Sync-Pipelines standardisiert anbindet und die regionale Cluster-Verteilung als Plattform-Funktion mitbringt.

Häufige Fragen (FAQ)

Was bedeutet Multi-Country E-Commerce-Suche?

Multi-Country E-Commerce-Suche bezeichnet die technische und organisatorische Aufgabe, eine zentrale Produkt-Suche so aufzubauen, dass sie pro Markt eine eigene Sicht auf das gemeinsame Stammdaten-Set liefert. Sechs Dimensionen sind pro Markt unterschiedlich: Sprache (lokalisierte Produktnamen, Tokenizer und Analyzer), Währung (Listen-Preise, Umrechnung), Sortiment (markt-spezifische Freigaben), Lagerbestand (pro Lagerort und Markt), Steuersätze (Mehrwertsteuer, Verbrauchssteuern) und Kategorisierung (markt-spezifischer Kategoriebaum). Die Aufgabe ist um eine Größenordnung komplexer als ein nationaler Shop derselben Größe, weil die Komplexität multiplikativ wächst. Jeder neue Markt bringt neue Sprachregeln, neue Pflege-Pipelines, neue Lager-Schnittstellen und neue Performance-Anforderungen.

Multi-Index oder Single-Index mit Markt-Filter, was ist besser?

Beide Strategien haben unterschiedliche Tradeoffs. Multi-Index legt pro Markt einen eigenen Such-Index an, mit markt-spezifischen Sprach-Analyzern, markt-spezifischen Preisen und Lagerbeständen. Vorteile: bessere Query-Performance, höhere Cache-Effizienz, unabhängige Update-Pipelines pro Markt. Nachteil: 18-fache Konfigurations-, Monitoring- und Backup-Pflege. Single-Index mit Markt-Filter hält alle Märkte in einem zentralen Index und filtert per market_filter. Vorteil: einfache Maintenance. Nachteile: schlechtere Query-Performance unter Last, geringere Cache-Effizienz, eng gekoppelte Update-Pipelines. Eine hybride Architektur kombiniert Multi-Index für markt-spezifische Daten mit einem zentralen Stammdaten-Index für nicht-markt-spezifische Felder. In der Praxis ist die hybride Architektur die häufigste Empfehlung für B2B-Plattformen mit 60.000 SKUs und 18 Märkten.

Wie geht eine internationale Suche mit verschiedenen Sprachen um?

Pro Markt wird ein eigener Sprach-Analyzer konfiguriert, der die markt-spezifischen Tokenisierungs- und Normalisierungs-Regeln anwendet. Germanische Sprachen mit Compound-Words (Deutsch, Niederländisch, Schwedisch) brauchen ein Compound-Decompounding-Wörterbuch. Romanische Sprachen mit Akzenten (Französisch, Italienisch, Spanisch, Portugiesisch) brauchen eine Akzent-Normalisierung. Slawische Sprachen mit reicher Morphologie (Polnisch, Tschechisch, Slowakisch) brauchen ein Stemming für die Beugungsformen. Finno-ugrische Sprachen (Finnisch, Ungarisch) brauchen eine Suffix-Erkennung für die agglutinierende Morphologie. Semitische Sprachen (Arabisch) brauchen Wurzel-Extraktion und Right-to-Left-Behandlung. Skandinavische Sprachen brauchen die korrekte Behandlung der Sonderzeichen å, ä, ö, ø, æ als eigenständige Buchstaben. Wer mit Standard-Analyzern arbeitet, bekommt eine Suche, die in den dominanten Märkten funktioniert und in den Randmärkten systematisch schlechtere Treffer liefert.

Sollen Preise im Such-Index gespeichert oder zur Query-Time berechnet werden?

Die Praxis-Antwort ist eine Mischung. Listen-Preise und Aktions-Preise werden im Index gespeichert, weil sie relativ stabil sind und die Preis-Filter und Preis-Sortierung dadurch schnell bleiben. Personalisierte Konditionen (B2B-Kunden-Rabatte) werden zur Query-Time berechnet, weil sie kunden-individuell sind. Brutto-Preise werden aus Netto-Preisen plus markt-spezifischem Steuersatz berechnet, entweder bei der Indexierung oder zur Query-Time je nach Last-Profil. Die Preis-Filter und Preis-Sortier-Logik müssen markt-aware sein und pro Markt das richtige Preis-Feld adressieren. In einer Multi-Index-Architektur ist das trivial, in einer Single-Index-Architektur müssen die Query-Templates pro Markt das richtige Feld auswählen.

Wie funktioniert Cross-Border-Spillover in der Such-Architektur?

Cross-Border-Spillover bezeichnet das Muster, bei dem ein Markt aus dem Lager eines anderen Marktes beliefert wird, weil das lokale Lager keinen Bestand hat. Beispiel: ein User in Österreich sucht ein Produkt, das im AT-Lager nicht vorrätig ist, aber im DE-Lager mit Cross-Border-Versand verfügbar wäre. Die Suche zeigt das Produkt mit einem Cross-Border-Hinweis und einer angepassten Lieferzeit-Angabe. Drei Bedingungen müssen erfüllt sein: SKU im Quell-Markt verfügbar (DE-Sortiments-Flag aktiv und DE-Lagerbestand größer null), SKU für Cross-Border-Versand freigegeben (regulatorische Freigabe pro SKU im PIM), Cross-Border-Konditionen für den Ziel-Markt bekannt (Lieferzeit, Versandkosten, Steuer-Berechnung). Die Such-Architektur bildet das typischerweise als zweistufige Abfrage ab: zuerst der Ziel-Markt-Index, dann falls Treffer unter Mindestschwelle der Quell-Markt-Index mit Cross-Border-Filter.

Wie hält man unter 200 Millisekunden Antwortzeit über 18 Märkte?

Drei Architektur-Antworten sind etabliert. Erstens regional verteilte Cluster: der Such-Cluster wird in mehreren Regionen betrieben (z. B. Frankfurt für EU, Dubai für MENA), Anfragen werden geo-geroutet auf den nächstgelegenen Cluster. Zweitens Edge-Caching für statische Treffer-Vorschläge und Filter-Vorschläge: sie werden auf CDN-Edge-Knoten gecached und direkt vom Edge-Knoten ausgeliefert. Drittens Pre-Loading der ersten Trefferseite über die Autocomplete-Mechanik: sobald der Endkunde mit dem Tippen anfängt, wird im Hintergrund die wahrscheinlichste Suche vorausberechnet. Die Latenz-Frage ist eine Architektur-Entscheidung, nicht eine Tuning-Aufgabe. Wer mit einem einzigen zentralen Cluster startet und erst bei steigender Last regional verteilt, hat eine längere Migrations-Phase vor sich. Wer von Anfang an regional plant, baut die Pipelines und Monitoring-Systeme so auf, dass die Skalierung auf neue Regionen mit überschaubarem Aufwand möglich ist.

Wie funktioniert die ERP- und PIM-Sync-Pipeline bei 18 Märkten?

Pro Markt müssen mehrere Daten-Quellen orchestriert werden: Stammdaten aus dem PIM, Bewegungsdaten aus dem ERP, Lokalisierungen aus dem TMS, Marketing-Daten aus dem CMS. Jede Quelle hat eigene Update-Frequenz und Liefer-Format. Drei Pattern haben sich durchgesetzt: zentrale Daten-Drehscheibe über einen Stream-Layer, der die Events markt-spezifisch in die Such-Indizes verteilt. Markt-spezifische Sync-Worker, die pro Markt aktiv pollen oder Event-Streams konsumieren und die Updates in den Such-Index pushen. Backfill-Pipelines für Schema-Migrationen über Blue-Green-Architektur, bei der ein neuer Index parallel zum alten befüllt und per Alias-Switch live geschaltet wird. Die Komplexität der Sync-Pipelines ist der Hauptgrund, warum viele Shops Multi-Country-Search nicht selbst aufbauen, sondern eine spezialisierte Infrastruktur einkaufen.

Bereit für eine Shop-Suche, die 60.000 SKUs über 18 Märkte konsistent durchsuchbar hält?

Eine sauber aufgesetzte Multi-Country-Such-Architektur kombiniert eine hybride Index-Strategie, markt-spezifische Sprach-Analyzer, lokale Lagerbestand-Sync-Pipelines, eine Currency- und Tax-bewusste Preis-Logik, Cross-Border-Spillover für die Randmärkte und regional verteilte Cluster für die Latenz-Garantie. Wer hier sauber baut, gewinnt Conversion-Rate über alle Märkte gleichermaßen, eine stabile Sortiments-Sicht über die Lagerbestände hinweg und eine Such-Infrastruktur, die mit jedem neuen Markt mitwächst, ohne dass das Shop-Backend zum Engpass wird. Volt Search® von BatteryIncluded ist als entkoppelte Infrastruktur Multi-Tenant aufgebaut. Pro Markt ein eigener Search-Tenant mit markt-spezifischem Analyzer, eigenem Preis-Modell, eigenem Lagerbestand-Feed und eigener Cross-Border-Mechanik. Hybrid LLM Search ergänzt die semantische Schicht, die Anfragen über Sprachen und Sortimente hinweg versteht. Cookieless, DSGVO-konforme KI, Made in Germany, ohne dass Sie 18-fach Search-Engineering aufbauen oder pro Markt ein eigenes Cluster betreiben müssen.

Zu Ihrer kostenlosen Demo und erleben Sie live an Ihren eigenen Produktdaten, wie Volt Search® die markt-spezifischen Sichten auf 60.000 SKUs konsistent ausliefert, wie der Sprach-Analyzer pro Markt die Tokenisierung anpasst, wie die Cross-Border-Logik die Randmärkte konvertiert und wie das Latency-Budget über alle Regionen stabil unter der 200-Millisekunden-Schwelle bleibt. Ohne eigenes Cluster, ohne User-Tracking, ohne lange Setup-Phase.