Bidirektionale Synchronisation ist fast immer ein Designfehler

Bidirektionale Synchronisation ist fast immer ein Designfehler

Wir bekommen diese Anfrage etwa zweimal im Monat. Sie klingt jedes Mal ähnlich. "Wir nutzen HubSpot fürs Marketing und Salesforce für den Vertrieb. Beide Systeme sollen dieselben Kontaktdaten halten. Bauen Sie uns einen bidirektionalen Sync?" Oder: "Wir arbeiten mit Notion intern und mit Confluence im Konzern. Wir brauchen, dass Änderungen auf beiden Seiten ankommen."

Unsere Antwort ist seit drei Jahren dieselbe: wir tun es nicht. Nicht, weil wir es technisch nicht könnten. Sondern weil wir es zu oft gebaut und danach zu oft repariert haben. Bidirektionale Synchronisation klingt simpel. Sie ist eine der heimtückischsten Architekturentscheidungen, die Sie in Ihrer Automatisierungslandschaft treffen können. Und in den meisten Fällen, in denen Sie sie wollen, brauchen Sie eigentlich etwas anderes.

Dieser Artikel ist länger als das, was wir sonst veröffentlichen, weil das Thema nicht in fünf Bulletpoints klärbar ist. Wir gehen die typischen Konfliktfälle durch, beschreiben, was in der Praxis passiert, und erklären die zwei Alternativen, die in 9 von 10 Fällen besser passen.

Was Sync wirklich heißt

Synchronisation klingt nach einer technischen Detailfrage. Sie ist eine Governance-Frage im technischen Gewand.

Wenn zwei Systeme dieselbe Information halten sollen, muss irgendjemand entscheiden, wer Recht hat, wenn beide Seiten anders aussehen. Dieser Satz ist die ganze Übung. Die meisten Teams überspringen ihn, weil die Antwort im Abstrakten naheliegend wirkt: man nimmt die jüngere Änderung, oder die aus dem führenden System, oder man mischt beide. Keine dieser Antworten überlebt den ersten Kontakt mit echten Daten.

Nehmen wir die Telefonnummer eines Kontakts. Eine Marketingkollegin aktualisiert sie in HubSpot, weil ein Datenanreicherungsanbieter eine neue Liste geliefert hat. Drei Stunden später aktualisiert ein Vertriebler dieselbe Nummer in Salesforce, weil der Kunde im Telefonat erwähnt hat, er habe ein neues Handy. Welche Nummer ist die richtige? Beide Personen handelten in gutem Glauben. Beide Systeme glauben, sie hätten die korrekte Antwort. Die Sync-Engine, die weder Kontext noch Urteilskraft hat, muss entscheiden.

Es gibt drei klassische Antworten, jede mit Folgen.

Sie können die jüngste Änderung gewinnen lassen. Das ist der Default der meisten Sync-Werkzeuge. Es funktioniert, bis es nicht mehr funktioniert. Ein Bug in HubSpot spielt nachts ein veraltetes Backup zurück. Die Salesforce-Änderung des Vertrieblers wird überschrieben. Niemandem fällt es eine Woche lang auf, bis sich der Kunde meldet, weil seine alte Nummer wieder im System ist.

Sie können eine Seite als führend deklarieren. Das ist die ehrlichste Option. Es ist auch kein bidirektionaler Sync mehr. Es ist ein unidirektionaler mit der höflichen Fiktion, dass die unterlegene Seite auch schreiben darf, wohl wissend, dass ihre Schreibvorgänge beim nächsten Sync überschrieben werden.

Sie können die Verantwortung pro Feld aufteilen. HubSpot besitzt Marketingfelder, Salesforce besitzt Vertriebsfelder. Beide Seiten lesen alles, beide schreiben nur ihre eigenen. Das ist die einzige Variante, die in der Praxis dauerhaft skaliert. Es ist, streng genommen, kein Sync mehr. Es ist Feld-Föderation mit einem Sync als Transportschicht.

Wenn wir Kunden durch diese drei Optionen führen, wollen die meisten zunächst Option eins. Nach drei oder vier durchgespielten Konfliktszenarien wollen die meisten Option drei. Und dann driftet das Gespräch zu der Frage, die es gleich am Anfang hätte eröffnen sollen: brauchen wir wirklich zwei beschreibbare Systeme, oder haben wir nur zwei Werkzeuge, die sich überlappen, weil niemand eine Entscheidung getroffen hat?

Sync-Loops, oder wie man sein Make-Abo zerstört

Bevor wir zu den Architekturempfehlungen kommen, ein technischer Hinweis. Bidirektionale Sync-Implementierungen haben eine Failure Mode, die in neun von zehn Fällen auftritt: den Sync-Loop.

So läuft es. System A ändert sich, ein Webhook feuert, die Sync-Engine schreibt die Änderung in System B. System B schickt selbst einen Webhook, weil sich etwas geändert hat. Die Sync-Engine schreibt die Änderung zurück in System A. System A schickt einen weiteren Webhook. Der Kreis schließt sich, bis etwas ihn stoppt.

In einer sauberen Architektur erkennt die Sync-Engine ihre eigenen Schreibvorgänge und ignoriert die daraus resultierenden Webhooks. In einer weniger sauberen Architektur, oder in einer mit einem Werkzeug gebaut, das diese Kontrolle nicht erlaubt, läuft der Loop, bis er ein Rate Limit, ein Quota-Cap oder einen Alarm trifft.

Wir hatten einen Kunden, dessen Make-Szenario zwischen Pipedrive und einer internen Datenbank Kontakte synchronisierte. Jede Nacht zwischen zwei und vier Uhr morgens passierte etwas Besonderes: ein separater Batch-Import berührte dieselben Datensätze. Die Sync-Engine konnte diese Änderungen nicht von menschlichen Bearbeitungen unterscheiden, drückte sie also brav nach Pipedrive, das sie ebenso brav zurückspiegelte. Der Loop lief zwei Stunden. Pipedrive juckte das nicht. Make schon. Das Zwei-Stunden-Fenster verbrauchte etwa 80.000 Operations. In der zweiten Wochenhälfte war das Monatsbudget des Make-Kontos aufgebraucht. Die Workflows blieben am Vierzehnten einfach stehen, ohne Warnung, außer einem Dashboard, das niemand beobachtete.

Sync-Loops zu verhindern ist nicht trivial. Sie müssen jede Änderung mit ihrer Herkunft markieren und Ihre Sync-Logik dazu bringen, ihre eigenen Änderungen zu ignorieren. Die meisten SaaS-Plattformen geben Ihnen dafür keinen sauberen Weg. Es gibt keine "setze dieses Feld, aber feuere keinen Webhook"-API. Sie bauen also Workarounds. Timestamps vergleichen. Hashes vergleichen. Verarbeitung 30 Sekunden verzögern. Jeder Workaround ist eine Stelle, an der das System von Ihrem Modell abweichen kann. Jeder Workaround wird die Ursache eines zukünftigen Ausfalls sein, dessen Diagnose Stunden frisst.

Zwei Systeme sind nie im selben Zustand

Selbst wenn der Loop technisch beherrscht ist, bleibt das Konsistenzproblem. Zwei Systeme können nicht zur gleichen Zeit denselben Zustand haben. Es gibt immer ein Zeitfenster, in dem eines weiter ist als das andere. Bei Webhook-basiertem Sync mit einer schnellen Engine sind das Sekunden. Bei Polling können es Minuten oder mehr sein.

In der Praxis bedeutet das: ein Vertriebler speichert eine Notiz in Salesforce und sieht zehn Sekunden später denselben Kontakt in HubSpot, aber ohne seine Notiz. Wenn er in HubSpot in diesem Moment eine andere Bearbeitung vornimmt, rasen die beiden Änderungen. Welcher Webhook zuerst bei der Sync-Engine ankommt, gewinnt. Welche das sein wird, ist nicht deterministisch.

Wir hatten einen Kunden, dessen wichtigste Kundin in HubSpot zwei unterschiedliche E-Mail-Adressen zeigte, je nachdem, welcher Mitarbeiter sie aufrief. Die Ursache war eine Replikationsverzögerung von vier bis sechs Minuten zwischen HubSpot und ihrem CRM. Zwei Personen hatten die Kundin im selben Viertelstundenfenster geöffnet. Jeder sah einen anderen Schnappschuss. Jeder bearbeitete. Die Sync-Engine löste den Konflikt, indem sie die ältere Bearbeitung behielt, weil deren CRM-Timestamp zufällig etwas früher war. Die "neuere" Änderung war aus menschlicher Sicht eigentlich die ältere. Keiner der beiden hatte sich falsch verhalten. Das System tat, was wir es gebeten hatten zu tun.

Verteilte Datenbanken wie Cassandra oder DynamoDB haben ganze Theoriekapitel zu dieser Klasse von Problemen. Sie nutzen Vector Clocks, CRDTs und explizite Tiebreaker, und sie machen das Konsistenzmodell zum Bestandteil des API-Vertrags. SaaS-Werkzeuge tun das nicht. HubSpot, Salesforce, Notion, Airtable: keines wurde mit der Annahme gebaut, dass zwei externe Systeme parallel denselben Datensatz beschreiben. Wenn Sie einen bidirektionalen Sync darauf aufbauen, schmuggeln Sie ein Distributed-Systems-Problem in eine Plattform, die nicht dafür ausgelegt ist, es zu lösen.

Wo bidirektionaler Sync tatsächlich passt

Es gibt einen schmalen Korridor, in dem bidirektionaler Sync vertretbar ist. In vier Jahren haben wir ihn vielleicht in jedem zehnten Fall erlebt.

Fall eins: beide Systeme sind echte Peers, mit getrennten Teams, die legitim auf denselben Datensatz schreiben müssen, und die Organisation hat die Disziplin, einen Konfliktauflösungsprozess zu betreiben. Wir haben das einmal für einen Finanzdienstleister mit zwei Geschäftsbereichen gebaut, jeder mit eigenem CRM, mit gemeinsamen Kunden zwischen beiden. Konflikte gehen in ein wöchentliches Review-Meeting. Ein Mensch entscheidet, kein Algorithmus.

Fall zwei: die synchronisierten Felder sind monoton. "Letzter Login-Zeitpunkt" kann nur größer werden. Wenn beide Systeme eine Version dieses Feldes tragen, gewinnt automatisch der spätere Wert. Konflikte sind mathematisch ausgeschlossen. Solche Felder sind in CRM-Daten selten, in operativen Kontexten kommen sie vor.

Fall drei: Schreibvorgänge sind so selten, dass Konflikte praktisch nie auftreten. Wenn der Vertrieb einen Datensatz einmal im Monat berührt und das Marketing einmal die Woche, kollidieren die beiden Seiten effektiv nie. Aber das ist eher ein Argument für minimale Komplexität als für bidirektionalen Sync. In so einem Fall reicht ein wöchentlicher Export plus ein höflicher Slack-Ping zu einem Bruchteil des Aufwands.

Außerhalb dieser drei Fälle ist unsere Antwort fast immer eines von zwei Alternativmodellen.

Alternative eins: System of Record mit Lesekopien

Wählen Sie ein System als Quelle der Wahrheit. Jedes andere System bekommt eine Kopie, die nach einem Zeitplan aktualisiert wird. Schreibvorgänge laufen in die Quelle der Wahrheit. Die Kopien aktualisieren sich beim nächsten Sync.

Das klingt restriktiv. Es ist auch restriktiv. Es ist auch das einzige Modell, das wir in Produktion länger als zwei Jahre stabil gesehen haben, ohne dass sich Datenqualitäts-Schulden anhäufen.

Für den HubSpot-Salesforce-Fall heißt das in der Regel: Salesforce ist die Quelle der Wahrheit für Kontaktdaten. HubSpot bekommt einen Refresh alle 30 Minuten und nutzt die Daten für Segmentierung, Listenbau und Kampagnen-Personalisierung. Wenn eine Marketingkollegin einen Kontakt aktualisieren muss, tut sie das über ein eingebettetes Salesforce-Formular oder über einen Workflow, der direkt nach Salesforce schreibt und auf den nächsten Refresh wartet, damit die Änderung in HubSpot ankommt.

Die User Experience ist anfangs schlechter als bei bidirektionalem Sync. Menschen sind es gewohnt, ihre Änderungen sofort zu sehen. Sie müssen lernen, dass die Änderung irgendwohin ging und das System, in das sie schauen, in ein paar Minuten nachzieht. Nach ein bis zwei Wochen ist das kein Problem mehr. Der Tausch lohnt sich: keine Konflikte, keine Loops, kein Audit-Albtraum, keine quartalsweise Datenqualitäts-Brandbekämpfung.

Welches System Sie als Quelle der Wahrheit wählen, ist eine politische, keine technische Entscheidung. Sie ist ein Statement darüber, wessen Daten im Konfliktfall gewinnen. Wer Salesforce wählt, sagt damit: der Vertrieb gewinnt. Wer HubSpot wählt, sagt: das Marketing gewinnt. Die Entscheidung gehört derjenigen Person, die konzeptionell die Kundendaten besitzt, meistens der Geschäftsführung oder dem Revenue-Verantwortlichen. Sie gehört nicht in Ihr Automatisierungsteam. Wir haben Projekte abgelehnt, in denen Kunden uns die Wahl überlassen wollten.

Alternative zwei: Feld-Föderation

Teilen Sie das Eigentum pro Feld auf, nicht pro System. HubSpot besitzt Newsletter-Opt-in, Marketing-Persona, letzte versendete Kampagne. Salesforce besitzt Deal-Stage, letzter Kontakt, nächster Schritt. Jedes System darf die fremden Felder lesen, beschreibt aber nur seine eigenen.

Das ist die Variante, mit der wir am häufigsten landen, wenn ein Kunde echte Schreibbedürfnisse auf beiden Seiten hat. Sie ist mühsamer auszurollen als das System-of-Record-Modell, weil die Mitarbeiter lernen müssen, welche Felder in welchem System leben. Wir adressieren das, indem wir nicht-beschreibbare Felder pro UI entweder ausblenden oder zumindest deutlich als "nur lesen" markieren. Wo das nicht geht, gibt es eine einseitige Anleitung, deren Link in jeder Onboarding-Mail für die betroffenen Teams steht.

Bei einem Kunden haben wir das mit ungefähr 80 Feldern pro Kontakt gebaut. Wir haben eine Tabelle erstellt mit vier Spalten: Feldname, besitzendes System, lesende Systeme, Schreibregeln. Die Tabelle wurde zum verbindlichen Dokument. Jedes neue Feld braucht einen Eintrag, bevor irgendein Sync gebaut wird. Zwei Jahre später ist die Tabelle auf etwa 120 Felder gewachsen, der Sync hatte seit achtzehn Monaten keinen konfliktbedingten Vorfall.

Der Aufwand, das aufzusetzen, ist höher als bei einem naiven bidirektionalen Sync. Der Aufwand, es zu betreiben, ist dramatisch niedriger. Wir rechnen unseren Kunden den zweiten Posten häufiger ab als den ersten.

Wenn Sie es trotzdem bauen wollen

Manche Kunden bestehen nach allen Warnungen auf bidirektionalem Sync. Wir tun es, mit einem Schadensbegrenzungsplan.

Wir loggen jeden Konflikt. Jeder erkannte Widerspruch geht in eine separate Datenbank: Zeitstempel, beide Versionen, gewählte Auflösung, Verweis auf die Quelldatensätze. Das ist die einzige Möglichkeit, im Nachhinein zu rekonstruieren, was passiert ist, wenn sich später jemand beschwert, seine Bearbeitung sei verloren gegangen.

Wir eskalieren mehrdeutige Konflikte an einen Menschen. Nicht jeder Konflikt ist regelhaft auflösbar. Wenn das System nicht entscheiden kann, erstellt es eine Aufgabe für eine festgelegte Person, die die richtige Version aussucht und zurückschreibt. Das ist langsam und teuer. Es ist auch die einzige ehrliche Möglichkeit, Datenqualität bei einem echten bidirektionalen Sync zu erhalten.

Wir begrenzen die Rate der Sync-Engine. Die Sync-Logik darf pro Minute nur eine begrenzte Anzahl von Schreibvorgängen ausführen. Wenn sie den Deckel zu sprengen droht, stoppt sie und alarmiert. Das ist Versicherung gegen Sync-Loops. Sie verhindert sie nicht vollständig, aber sie verhindert, dass sie zwei Stunden lang unbemerkt laufen.

Wir planen Audit-Läufe. Einmal pro Woche iteriert ein Prozess über jeden synchronisierten Datensatz und vergleicht beide Seiten. Diskrepanzen kommen in einen Report. Eine Person prüft den Report und entscheidet, was zu tun ist.

Zusammen kosten diese vier Kontrollen viel. Sie sind der Preis eines ernst gemeinten bidirektionalen Syncs. In den meisten Fällen ist es billiger, von Anfang an eines der Alternativmodelle zu wählen, auch nachdem man die politische Arbeit eingerechnet hat, den Kunden davon zu überzeugen.

Die Frage hinter der Frage

Wenn ein Kunde uns nach bidirektionalem Sync fragt, fragen wir warum. Welches Problem soll der Sync lösen?

Die Antworten landen in einem überschaubaren Bündel.

"Damit beide Teams dieselben Daten sehen." Dafür reicht ein unidirektionaler Sync von System A nach System B, kombiniert mit der Regel, dass Schreibvorgänge in A passieren. Beide Teams sehen dieselben Daten. Nur eines kann sie ändern.

"Damit Mitarbeiter im Werkzeug arbeiten können, das sie bevorzugen." Das ist meistens eine höfliche Version von "wir haben zwei sich überlappende Werkzeuge gekauft und keiner will eines abgeben". Die ehrliche Lösung ist Konsolidierung, nicht Sync. Sync überdeckt die Duplizierung und macht sie permanent.

"Für Flexibilität, falls wir das Master-System später wechseln." Das ist die teuerste Antwort. Sie zahlen heute echten Implementierungsaufwand für eine Option, die Sie wahrscheinlich nie ausüben werden. Wenn Sie das Master-System tatsächlich später wechseln, ist die Migration ein eigenes geplantes Projekt. Sie profitiert nicht von einer Sync-Architektur, die Sie vor zwei Jahren aus einem anderen Grund gebaut haben.

"Für Resilienz, falls ein System ausfällt." Bidirektionaler Sync macht Sie nicht resilienter. Er macht Sie fragiler. Wenn eines der Systeme nicht erreichbar ist, stoppt der Sync, und die beiden Seiten driften. Wenn das andere System wieder online ist, müssen Sie versöhnen. Resilienz kommt aus Backups und klaren Failover-Regeln, nicht aus Sync.

Wenn wir die Frage stellen, antworten Kunden beim zweiten Versuch meistens vorsichtiger. Die Antworten werden weniger abstrakt. Sie zeigen, dass das echte Problem etwas anderes ist, manchmal etwas Organisatorisches, das keine Sync-Engine reparieren kann.

Symptome eines kaputten bidirektionalen Syncs

Wir werden manchmal gerufen, weil ein Sync "nicht ganz wie erwartet" läuft. Die folgenden Symptome haben wir in fast jedem dieser Fälle gesehen. Wenn drei oder mehr davon auf Sie zutreffen, ist es Zeit für ein ernsthaftes Gespräch.

Erstes Symptom: das Operations-Team führt eine "Korrektur-Liste". Eine Tabelle, ein Sheet, eine Notion-Seite, irgendetwas, in dem Datensätze stehen, "die nach dem Sync neu von Hand geprüft werden müssen". Wenn Sie so etwas haben, ist Ihr Sync nicht der Mechanismus, den er vorgibt zu sein. Er ist eine teilautomatisierte Kopierhilfe mit manuellem Aufräumdienst.

Zweites Symptom: monatliche Datenqualitätsreports zeigen schwankende Werte, ohne dass sich die operative Realität ändert. Wenn die Anzahl "vollständiger Kontakte" mal 87 Prozent, mal 91 Prozent, mal 84 Prozent beträgt, je nach Tag der Messung, leidet die Datenkonsistenz unter dem Sync. Die Schwankungen entstehen, weil Konflikte ungleich aufgelöst werden, je nachdem, wer zufällig zuletzt geschrieben hat.

Drittes Symptom: Mitarbeiter haben Workarounds gebaut, um den Sync zu umgehen. Sie speichern sich Kundendaten in einer privaten Excel-Datei, weil sie der zentralen Datenquelle nicht mehr trauen. Sie fragen vor jeder wichtigen Änderung beim Kollegen nach, ob er nicht gerade dran ist. Diese Workarounds entstehen, weil das System nicht tut, was die Mitarbeiter brauchen.

Viertes Symptom: Support-Tickets enthalten häufig die Formulierung "die Daten haben sich verändert, ohne dass ich etwas getan habe". Das ist der klassische Sync-Loop-Fingerabdruck. Wenn Mitarbeiter berichten, dass Felder über Nacht wieder ihren alten Wert annehmen, ist irgendwo eine Sync-Schleife aktiv, die ihre Bearbeitung überschreibt.

Fünftes Symptom: niemand weiß genau, welcher Workflow auslösend war, wenn ein Konflikt auftritt. Die Logs sind unvollständig oder verteilt über drei Werkzeuge. Eine Konfliktuntersuchung dauert zwei Stunden, weil man durch Make, das ERP und das CRM springen muss, um die Ereigniskette zu rekonstruieren.

Sechstes Symptom: die Plattformkosten für den Sync sind im letzten Jahr um mehr als 30 Prozent gestiegen, ohne dass sich das Datenvolumen entsprechend erhöht hat. Das ist ein Hinweis auf wachsende Konfliktauflösungsoperationen, auf nachträgliche Korrekturen, auf wiederholt fehlgeschlagene Schreibvorgänge, die immer wieder neu ausgeführt werden.

Diese Symptome treten selten allein auf. Wenn Sie eines sehen, suchen Sie nach den anderen. In den meisten Audits, in denen wir nach diesen Mustern fragen, findet das Team mehrere davon. Das ist der Punkt, an dem die Diskussion über Migration ernsthaft werden sollte.

Wenn Sie schon bidirektional gebaut haben: ein Migrationspfad

Wir bekommen auch die andere Anfrage. "Wir haben vor zwei Jahren bidirektionalen Sync gebaut. Das funktioniert nicht. Können Sie uns helfen, da rauszukommen, ohne die Operationen zu stoppen?" Die Antwort ist ja, aber der Weg ist länger, als die meisten erwarten.

Schritt eins: messen, was wirklich passiert. Bevor irgendetwas geändert wird, brauchen wir Zahlen. Wie viele Konflikte gab es im letzten Monat? Wie viele Datensätze sind auf beiden Seiten verschieden? Welche Felder sind die häufigsten Konfliktherde? Diese Messung ist meistens unangenehm, weil sie offenlegt, was lange ignoriert wurde. Sie ist auch die einzige Grundlage, auf der die Migration sinnvoll geplant werden kann.

Schritt zwei: pro Feld entscheiden, wer gewinnt. Mit der Tabelle aus dem Feld-Föderations-Modell als Vorlage. Die Entscheidung wird gemeinsam mit den Fachbereichen getroffen. Sie ist politischer Natur. Manchmal merken wir an dieser Stelle, dass es gar nicht so viele wirkliche Streitfälle gibt. Die meisten Felder sind eindeutig dem einen oder anderen System zuzuordnen, wenn man die Frage einmal explizit stellt.

Schritt drei: Schreibrechte in einer Seite technisch entfernen. Das ist der heikelste Schritt. Sie müssen Benutzern erklären, warum sie ab Montag bestimmte Felder nicht mehr im gewohnten System bearbeiten können. Es gibt immer Widerstand. Wir empfehlen, das in Wellen zu machen: pro Woche fünf bis zehn Felder umstellen, mit Vorankündigung, mit klarem Verweis darauf, wo die Felder jetzt zu bearbeiten sind.

Schritt vier: alten bidirektionalen Sync abschalten und durch unidirektionalen ersetzen. Das ist technisch die einfachste Übung, sobald die ersten drei Schritte abgeschlossen sind. Die meisten Sync-Engines haben einen Richtungsschalter, der von "bidirectional" auf "A nach B" gestellt werden kann. Der Schalter macht aus einer komplexen Architektur eine einfache.

Wir haben diese Migration für drei Kunden durchgeführt. Sie dauert zwischen sechs Wochen und vier Monaten, je nach Anzahl der Felder und Intensität des politischen Widerstands. Sie ist nie schnell. Sie ist immer machbar. Und das Ergebnis ist eine Datenarchitektur, die in zwei Jahren noch wartbar ist.

Was die Plattformen verstehen und was nicht

Nicht jede Plattform behandelt bidirektionalen Sync gleich. Ein paar Beobachtungen aus der Praxis.

Zapier hat in seinen Out-of-the-Box-Integrationen kaum Konfliktauflösungslogik. Ein "Zwei-Wege-Sync"-Zap ist meistens zwei separate Zaps, die in unterschiedliche Richtungen laufen, mit allen Konsequenzen. Die Sync-Loop-Prävention beschränkt sich auf rudimentäre Timestamp-Vergleiche, die in komplexen Szenarien versagen. Für ernsthaften bidirektionalen Sync ist Zapier kein gutes Werkzeug.

Make.com hat den Vorteil, dass Sie mehr Kontrolle über jede einzelne Operation haben. Sie können explizit Marker setzen, Headers vergleichen, Webhook-Quellen filtern. Das macht das Werkzeug für bidirektionalen Sync besser geeignet als Zapier, aber auch wesentlich aufwändiger im Aufbau. Wir haben in einer Implementierung sechs Wochen gebraucht, um die Konfliktbehandlung sauber zu modellieren.

n8n bietet wegen seiner JavaScript-Möglichkeit theoretisch den meisten Spielraum. Sie können beliebige Konfliktlogik im Code abbilden. Sie können auch Bibliotheken integrieren, die Last-Writer-Wins mit expliziten Tiebreakern umsetzen. Der Nachteil: Sie verlassen die visuelle Schicht und landen in einem Modell, das nicht wesentlich einfacher ist als ein eigenes Microservice. Wenn Sie schon da sind, sollten Sie auch ein Microservice in Betracht ziehen, das genau diese eine Aufgabe sauber löst.

Spezialisierte Werkzeuge wie PieSync, das von HubSpot übernommen wurde und in Operations Hub aufging, oder Census versuchen, das Problem auf der Architekturebene zu lösen. Sie sind erkennbar besser für echte Sync-Szenarien als die generischen Workflow-Tools. Sie kosten auch deutlich mehr, und sie funktionieren nur für die Integrationsketten, die sie explizit unterstützen. Wer eine sehr standardisierte Architektur hat, kann mit ihnen die Implementierungsarbeit deutlich verkürzen. Wer Sonderanforderungen hat, landet schnell wieder beim Aufbau eigener Workarounds.

Eine generelle Beobachtung. Je mehr Kontrolle Ihnen ein Werkzeug für die Konfliktbehandlung gibt, desto mehr Verantwortung müssen Sie übernehmen. Es gibt keinen Sync, der "einfach so" funktioniert. Es gibt nur Sync, der gerade so lange funktioniert, bis der erste echte Konflikt auftritt.

Eine letzte Geschichte

Vor zwei Jahren wechselte ein Kunde auf ein neues HR-System. Das alte System sollte parallel laufen, weil einige historische Auswertungen davon abhingen. Die HR-Abteilung wollte bidirektionalen Sync, "damit Aktualisierungen in beide Richtungen fließen, falls jemand das alte System aus Versehen anrührt".

Wir saßen drei Stunden zusammen und spielten jeden Konfliktfall durch, den wir uns vorstellen konnten. Am Ende schlugen wir etwas anderes vor. Das neue System ist die Quelle der Wahrheit. Das alte System wird einmal pro Nacht mit einem Snapshot überschrieben. Auswertungen gegen das alte System sind maximal 24 Stunden alt, was für historische Zwecke unproblematisch ist. Schreibvorgänge im alten System sind technisch deaktiviert.

Der Bau dauerte zwei Wochen. Ein echter bidirektionaler Sync hätte vier Wochen gedauert, plus laufende Konfliktauflösung, plus wöchentliche Audits. Über drei Jahre gerechnet hätte die "einfache" bidirektionale Variante das Sechs- bis Achtfache gekostet, ohne realen Mehrwert.

Drei Monate später erzählte uns die HR-Leitung, das alte System würde kaum noch angefasst. Die parallele Schreibmöglichkeit, die sie ursprünglich für unverzichtbar gehalten hatten, brauchte niemand. Sechs Monate später wurde das alte System endgültig abgeschaltet.

So läuft es nicht jedes Mal. Manchmal ist der zweite Schreibpfad wirklich nötig. Aber unsere Erfahrung ist: die Frage, ob er wirklich nötig ist, wird in Diskussionen viel zu selten gestellt. Sie wird vorausgesetzt, weil die ursprüngliche Anforderung lautete "die beiden Systeme sollen synchron sein".

Zum Schluss

Bidirektionaler Sync ist kein Feature. Er ist eine Architekturentscheidung mit erheblichen Folgekosten. Ohne explizite Konfliktauflösung, ohne Sync-Loop-Prävention und ohne eine Haltung zur Eventual Consistency entstehen Datenqualitätsprobleme, die nach zwölf bis achtzehn Monaten unreparierbar werden.

In den meisten Fällen ist eines der zwei Alternativmodelle die bessere Wahl. System of Record mit unidirektionalem Sync zu Lesekopien, oder Feld-Föderation mit klaren Schreibverantwortungen pro Feld. Beide Modelle erzeugen weniger Komplexität, weniger Konfliktfälle und weniger laufenden Wartungsaufwand. Beide sind in der Implementierung manchmal aufwändiger als ein naiver bidirektionaler Sync. Beide sind im Betrieb deutlich günstiger.

Wenn Sie gerade überlegen, einen bidirektionalen Sync zwischen zwei Geschäftsanwendungen aufzubauen, ist ein 30-minütiges Architekturgespräch mehr wert als ein Dutzend Support-Tickets in zwölf Monaten. In unserem kostenlosen Automations-Check gehen wir das mit Ihnen durch. Erfahrungsgemäß ist die Antwort, dass Sie keinen bidirektionalen Sync brauchen. Sondern etwas, das von außen wie einer aussieht, mit deutlich weniger Risiko von innen.