ERP-Shopify-Integration: 5 Architektur-Muster aus der Praxis

ERP-Sync ist der Bereich, in dem Shopify-Plus-Projekte am häufigsten kentern. Apps versprechen “Plug & Play” - die Realität sind Stunden in Edge-Cases, Race-Conditions und Datenstörungen. Hier sind die fünf Architektur-Muster, die wir in echten Plus-Projekten erfolgreich umgesetzt haben.

Was ERP-Sync eigentlich umfasst

Bevor wir über Architektur reden, klären wir, was synchronisiert wird:

• Produkte (Master-Daten, Varianten, Bilder, Beschreibungen)
• Bestände (Lager pro SKU, oft mehrere Lager-Standorte)
• Preise (B2C, B2B, Currency, Promotions)
• Bestellungen (Order-Capture aus Shopify zurück in ERP)
• Kunden (Profile, B2B-Companies, Tax-Status)
• Rechnungen / Gutschriften (in ERP erzeugt, in Shopify als Reference)

Jede dieser Domains kann unterschiedliche Sync-Frequenzen und -Richtungen brauchen. One-Size-Fits-All gibt es nicht.

Muster 1: Direct API-to-API (Real-Time)

ERP ──webhook──> Middleware (Cloudflare Worker) ──REST API──> Shopify
                                                  <──REST API── (für Order-Capture)

Pros:

• Echtzeit-Daten in beide Richtungen
• Volle Kontrolle über Mapping und Edge-Cases
• Skaliert sauber bis sehr hohe Order-Frequenz

Cons:

• Engineering-Aufwand (4–10 Wochen Setup)
• Eigenes Monitoring und Retry-Logic nötig

Wann wir es empfehlen: Plus-Brands ab 5K Orders/Monat mit eigenem Engineering-Team oder uns als Partner.

Muster 2: Batched-Sync via Queue (Near-Real-Time)

ERP ──Event──> Message Queue (RabbitMQ, AWS SQS) ──Worker──> Shopify
Shopify ──Webhook──> Queue ──Worker──> ERP

Pros:

• Resilient gegen API-Rate-Limits und ERP-Downtime
• Saubere Trennung der Domains
• Retry und Dead-Letter-Queues machen Fehler-Handling robust

Cons:

• Latenz von Sekunden bis Minuten (statt Millisekunden)
• Mehr Infrastruktur

Wann wir es empfehlen: B2B-Brands mit komplexer Geschäftslogik oder mehreren ERP-Systemen.

Muster 3: iPaaS-basiert (Integromat/Make, Workato, n8n)

ERP ──API/Webhook──> iPaaS-Plattform ──API──> Shopify

Pros:

• Schneller Setup (1–3 Wochen)
• No-Code-Logic, leicht änderbar
• Bestehende Connectoren für Standard-ERPs

Cons:

• Skaliert bis ~1K Orders/Tag, dann teuer
• Eingeschränkte Edge-Case-Handhabung
• Vendor-Lock-in

Wann wir es empfehlen: Brands bis ~3K Orders/Monat, B2C-fokussiert, ohne komplexe Custom-Logic.

Muster 4: Polling-basiert (Legacy ERPs)

Shopify <── Cron-Job (jede 5 Min.) <── Custom-Worker (liest ERP DB) <── ERP DB

Pros:

• Funktioniert auch mit ERPs ohne API (SQL-Direct-Read als Notlösung)
• Einfach zu debuggen
• Robust bei ERP-Downtime (Worker wartet einfach)

Cons:

• Schlecht skalierbar
• Polling-Latenz
• Direct-DB-Read ist Anti-Pattern, wenn vermeidbar

Wann wir es empfehlen: Übergangs-Lösung bei alter SAP B1, JTL Wawi 1.x oder Legacy-WaWi-Systemen, bis API-Layer steht.

Muster 5: Reverse-ETL mit Data Warehouse als Hub

ERP ──ETL──> Data Warehouse (Snowflake, BigQuery)
Shopify ──ETL──> Data Warehouse
Data Warehouse ──Reverse-ETL (Hightouch, Census)──> Shopify (+ Klaviyo + ...)

Pros:

• Single-Source-of-Truth im DWH
• Komplexe Logik (Pricing-Modelle, Segmentation) im DWH leichter
• Saubere Auditierbarkeit

Cons:

• Hoher Initial-Aufwand
• Latenz von Stunden (nicht für Echtzeit-Bestand)
• DWH-Kosten

Wann wir es empfehlen: Brands mit eigener Data-Team oder im Konzern-Verbund, wo das DWH ohnehin existiert.

Vergleichs-Tabelle der Muster

Muster	Setup	Latenz	Skalierung	Best-Fit
Direct API	4–10 Wo.	Sekunden	Sehr hoch	Plus-Brand mit Engineering
Queue-basiert	6–12 Wo.	1–5 Min	Hoch	B2B oder Multi-ERP
iPaaS	1–3 Wo.	1–10 Min	Mittel	B2C bis 3K Orders/Monat
Polling	1–2 Wo.	5–15 Min	Niedrig	Legacy-ERP-Übergang
Reverse-ETL	4–8 Wo.	1–6 Std	Hoch	Brands mit DWH

Häufige Stolperfallen

Stolperfalle 1: Race-Conditions bei Bestand

Wenn Order in Shopify einläuft und gleichzeitig ERP einen Bestands-Update sendet, kann dein Bestand kurz negativ werden. Lösung: Reservation-Logic in der Middleware mit kurzem TTL (5–15 Min), bevor finalized.

Stolperfalle 2: Bidirektionale Updates auf gleichem Feld

Wenn Shopify und ERP beide den Preis ändern können, gewinnt der letzte Update - und überschreibt deinen anderen Source. Lösung: Source-of-Truth-per-Field definieren. Preise: ERP gewinnt. Tags und Marketing-Texte: Shopify gewinnt.

Stolperfalle 3: ID-Mapping verloren

Wenn ein Produkt im ERP gelöscht wird und neu angelegt, läuft dein Mapping leer. Lösung: Mapping-Table in der Middleware mit beiden IDs + Bestellungs-Audit-Log.

Stolperfalle 4: Sync-Loop

ERP sendet Update → Shopify aktualisiert → Shopify sendet Webhook → Middleware glaubt, ein neues Update sei nötig → Sync-Loop. Lösung: Origin-Marker im Payload (source: erp) und im Worker abprüfen.

Stolperfalle 5: Keine Idempotenz

Webhooks werden gelegentlich doppelt zugestellt. Wenn deine Logik nicht idempotent ist, hast du doppelte Bestellungen im ERP. Lösung: Deduplication via Order-ID im Worker.

Unsere Default-Empfehlung

Für die meisten DACH-Plus-Brands empfehlen wir:

• B2C bis 5K Orders/Monat: iPaaS (n8n self-hosted oder Make)
• B2C >5K Orders/Monat: Direct API mit Cloudflare Workers
• B2B: Queue-basiert mit klarem Source-of-Truth-Mapping
• Legacy-ERP: Übergangs-Polling, mit klarem Sunset-Plan auf API-Layer

---

ERP-Sync ist nie “schnell mal eingerichtet” - aber mit dem richtigen Muster ist es eine stabile Foundation. Wenn du gerade eine Integration planst oder eine bestehende reparieren musst: Lass uns 30 Minuten sprechen - wir teilen unsere Erfahrungen und schlagen ein Muster vor.