Webflow CMS Sync: Wie Conflict Detection funktioniert

Der bidirektionale Sync zwischen Collections und Webflow CMS ist eine der komplexesten Funktionen der Plattform. In diesem Beitrag erklaeren wir, wie die Conflict Detection technisch aufgebaut ist und welche Design-Entscheidungen dahinter stehen.

Das Problem: Zwei Systeme, eine Wahrheit

Wenn Daten sowohl in unserer Plattform als auch in Webflow bearbeitet werden können, entsteht ein klassisches Distributed-Systems-Problem. Welche Version ist die richtige, wenn beide Seiten seit dem letzten Sync geaendert wurden?

Field-Level Mapping

Jedes Collection-Feld wird auf ein Webflow-CMS-Feld gemappt. Das Mapping ist explizit -- kein Feld wird automatisch synchronisiert, wenn es nicht konfiguriert ist. Das gibt euch volle Kontrolle darüber, welche Daten fliessen und welche nicht.

Timestamp-basierte Conflict Detection

Bei jedem Sync vergleichen wir die Zeitstempel der letzten Änderung auf beiden Seiten. Wenn ein Feld in beiden Systemen seit dem letzten Sync geaendert wurde, wird ein Conflict erkannt und markiert. Ihr koennt dann manuell entscheiden, welche Version gewinnt -- oder eine Merge-Strategie definieren.

Push-Strategien

Wir unterstuetzen drei Modi: Single Push für individuelle Datensaetze, Bulk Push für ganze Collections und Auto-Sync für Echtzeit-Synchronisation. Auto-Sync nutzt Webhooks, die bei jeder Änderung in unserer Plattform gefeuert werden.

MD5-Vergleich für Assets

Bei Assets reicht ein Timestamp nicht: Hat sich die Datei wirklich geaendert oder nur Metadaten? Wir berechnen MD5-Hashes für jede Datei und vergleichen diese beim Sync. Nur wenn der Hash abweicht, wird die Datei neu gepusht.

Retry-Logik und Sync-Status

Die Webflow API hat Rate Limits und kann unter Last langsamer reagieren. Wir implementieren exponential Backoff mit maximal 3 Retries pro Request. Jedes Asset hat einen eigenen Sync-Status: synced, pending, failed oder not pushed.