Logische Replikation vs Batch-ETL: Wahl des Sync-Stils

Welches Problem lösen wir, wenn wir „Daten synchronisieren“?\n\nTeams kopieren Daten zwischen Systemen, weil Arbeit selten an einem Ort passiert. Sales sitzt vielleicht im CRM, Zahlungen in einem Billing-Tool und Operations in einem internen Dashboard. Support braucht den kompletten Überblick, ohne zwischen Tools zu springen, und Führungskräfte wollen Reports, die dem tatsächlichen Geschehen entsprechen.\n\nEine „vertrauenswürdige Synchronisation“ ist leicht zu beschreiben und schwer aufrechtzuerhalten: die richtigen Datensätze kommen an, nichts Wichtiges fehlt, und Updates erscheinen schnell genug, um nützlich zu sein. „Schnell genug" hängt vom Anwendungsfall ab. Betrugserkennung braucht vielleicht Minuten, monatliche Finanzberichte vertragen Stunden.\n\nWenn ein Sync schiefgeht, äußert sich das meist durch fehlende Datensätze, Duplikate, veraltete Felder oder partielle Updates (zum Beispiel erscheint die Bestell-Überschrift, aber die Positionen fehlen).\n\nEin nützliches Denkmodell ist Events vs. Snapshots.\n\nEvents sind einzelne Änderungen: „Bestellung #1842 wurde erstellt“, „Status auf versendet geändert“, „Rückerstattung ausgeführt“. Change-Data-Ansätze bewegen oft Events und können nahezu in Echtzeit arbeiten.\n\nSnapshots sind geplante Kopien: „jede Nacht, kopiere die Bestellungen von gestern“. Batch-ETL funktioniert häufig so. Es kann einfacher sein, aber die Daten sind weniger frisch.\n\nDie meisten Debatten über logische Replikation vs Batch-ETL drehen sich eigentlich um diese Frage: braucht ihr fortlaufende Events, oder genügen periodische Snapshots, damit die Nutzer dem, was sie sehen, vertrauen?\n\n## Logische Replikation und Batch-ETL, einfach erklärt\n\nLogische Replikation bedeutet, dass die Quell-Datenbank einen Strom von Änderungen sendet, sobald sie passieren. Statt ganze Tabellen zu kopieren, werden „Zeile hinzugefügt“, „Zeile aktualisiert“ oder „Zeile gelöscht“ veröffentlicht. Das Zielsystem wendet diese Änderungen in der Reihenfolge an, sodass es eng mit der Quelle übereinstimmt.\n\nBatch-ETL heißt, du nimmst Snapshots nach einem Zeitplan. Ein Job extrahiert Daten (oft „alles seit dem letzten Lauf“), transformiert sie bei Bedarf und lädt sie ins Ziel. Wenn Replikation wie Live-Updates wirkt, fühlt sich Batch-ETL an, als würdest du stündlich (oder jede Nacht) einchecken und aufholen.\n\nSie laufen meist an unterschiedlichen Orten. Replikation sitzt nah am Change-Log der Datenbank und läuft kontinuierlich. Batch-ETL ist typischerweise ein geplannter Job, der startet, stoppt und wieder startet.\n\nSo oder so musst du dieselben Vertrauensfragen beantworten:\n\n- Wie werden Löschungen dargestellt, damit das Ziel keine „Geister“-Zeilen behält?\n- Was passiert, wenn dieselbe Änderung zweimal ankommt (Idempotenz)?\n- Wie bleibt die Reihenfolge korrekt, wenn viele Zeilen schnell geändert werden?\n- Wie vermeidest du verlorene Änderungen bei Neustarts oder Deploys?\n- Wie erkennst du Lücken, und nicht nur „Job erfolgreich“?\n\nBeispiel: Eine Bestellung wird erstellt, dann ändert sich der Status von „pending“ zu „paid“, dann wird sie erstattet. Replikation sendet drei Änderungs-Events. Ein täglicher Snapshot erfasst möglicherweise nur den Endstatus, es sei denn, das Batch-Design bewahrt Zwischenzustände.\n\n## Frische und Latenz: wie nah an Echtzeit brauchst du es?\n\nBevor du Replikation und Batch-ETL vergleichst, definiere „frisch genug“ in Geschäftszahlen. Fang mit einer Zahl an: „Support kann mit Daten bis zu 5 Minuten Alter arbeiten“ oder „Finance ist mit den Summen von gestern zufrieden“.\n\nFrische ist das Alter der Daten, wenn jemand sie nutzt. Latenz ist die Verzögerung zwischen einer Änderung in der Quelle und dem selben Update im Ziel. Du kannst niedrige durchschnittliche Latenz haben und trotzdem „alte“ Daten, wenn der Sync häufig ins Stocken gerät.\n\n### Wo Latenz wirklich herkommt\n\nSelbst ein einfacher Sync stapelt mehrere Verzögerungen: Erfassung (wann du Änderungen bemerkst), Transit (Datenübertragung), Verarbeitung (Transformationen und Deduplizierung) und Anwenden (Schreiben und Indizieren im Ziel).\n\nEin konstanter Tropfen (Replikation oder häufige Micro-Batches) liefert gleichmäßige Frische, aber du betreibst den Sync den ganzen Tag. Geplante Batches sind leichter zu verstehen, erzeugen aber Spitzen: hohe Last um 2:00 Uhr und dann veraltete Daten bis zum nächsten Lauf.\n\nNahezu in Echtzeit hilft, wenn Entscheidungen schnell getroffen werden oder Kunden Ergebnisse sofort sehen. Ein Support-Dashboard sollte neue Bestellungen schnell zeigen, damit ein Agent nichts verspricht, was nicht mehr auf Lager ist. Wenn es aber hauptsächlich um wöchentliche Reports oder monatliche Abrechnungen geht, erhöht das sofortige Pushen vieler kleiner Updates die Komplexität ohne echten Nutzen.\n\nEin praktischer Entscheidungsweg:\n\n- Wer nutzt die synchronisierten Daten und welche Entscheidungen treffen sie damit?\n- Was geht kaputt, wenn die Daten 15 Minuten alt sind?\n- Was kostet der kontinuierliche Betrieb (Infrastruktur und On-Call-Aufwand)?\n- Wann ist das Zielsystem am wenigsten beschäftigt?\n- Welcher Frischewert wird fest versprochen (und kommuniziert)?\n\n## Ausfallwiederherstellung: wie man nach einem Fehler wieder korrekt wird\n\nSyncs fallen selten dramatisch aus. Sie scheitern auf kleine, langweilige Weise: ein Server startet neu, ein Netzwerkbrummen trennt die Verbindung oder ein Job crasht mitten im Laden. Das Ziel ist nicht „nie ausfallen“, sondern „auf einen korrekten Endzustand wiederherstellen“.\n\nTypische Ausfallarten sind Quell-Ausfall, Ziel-Ausfall, Job-Crash während der Verarbeitung oder fehlerhafte Daten, die Constraints verletzen.\n\nBei logischer Replikation bedeutet Wiederherstellung meist das Wiederabspielen von Änderungen ab einer gespeicherten Position (oft ein Log-Offset). Wenn das Ziel down ist, stauen sich Änderungen, bis es wieder da ist, und werden dann in Reihenfolge angewendet. Das ist sauber, wenn du die Replikations-Slots (oder Äquivalente) verwaltest, damit sie bei langen Ausfällen nicht ewig wachsen.\n\nBei Batch-ETL bedeutet Wiederherstellung oft das erneute Ausführen eines Zeitfensters (z. B. „lade gestern neu“ oder „reload der letzten 2 Stunden“). Das ist operativ oft einfacher, aber deine Lade-Logik muss sicher mehrfach laufen können.\n\nDer größte Vertrauensbrecher sind partielle Writes. Ein Crash nach dem Schreiben von 70 % eines Batches kann Duplikate oder fehlende Zeilen hinterlassen, wenn du das nicht planst. Muster, die in beiden Stilen helfen:\n\n- Mache Loads idempotent, sodass zweimaliges Anwenden zum selben Zustand führt.\n- Bevorzuge Upserts, die durch einen stabilen Primärschlüssel getrieben sind.\n- Verschiebe deinen "last processed"-Marker erst nach einem erfolgreichen Commit.\n- Bewahre abgelehnte Zeilen an einem Ort auf, den du inspizieren und erneut abspielen kannst.\n\nBackfills (Historie neu berechnen) zeigen Schmerzen oft deutlich. Batch-ETL gewinnt oft, wenn du einen Monat Daten neu verarbeiten musst, weil Reruns Teil des Designs sind. Replikation kann backfillen, aber das ist üblicherweise ein separater Pfad (zuerst Snapshot, dann Änderungen anwenden), also teste das, bevor du es brauchst.\n\nBeispiel: Wenn ein Orders-Sync crasht, nachdem die Positionen geschrieben, aber bevor die Header geschrieben wurden, verhindert ein Upsert-basierter Load mit einer Transaktion pro Bestellung (oder pro Batch) eine halb synchronisierte Bestellung, die stehen bleibt.\n\n## Schema-Evolution: was passiert, wenn sich das Datenmodell ändert?\n\nSchema-Änderungen sind ein häufiges Problem, bei dem viele Syncs still das Vertrauen verlieren. Eine Pipeline kann weiterlaufen, während sich die Bedeutung der Daten darunter verschiebt. Replikation kann auf DB-Ebene brechen, ETL bricht oft später in Transformationen und Reports.\n\nAdditive Änderungen sind am einfachsten: neue Spalten, neue Tabellen, neue optionale Felder. Sie funktionieren meist, wenn Konsumenten sie als „extra“ behandeln und Defaults sinnvoll sind. Die Falle ist die Annahme, dass jeder Downstream-Konsument das neue Feld bemerkt oder weiß, wie man es backfilled.\n\nBrechende Änderungen sind riskant: Umbenennungen, Typänderungen, gelöschte Spalten oder Bedeutungsänderungen. Diese können schnell fehlschlagen (Job-Fehler) oder langsam (falsche Daten landen).\n\n### Sicher weiterentwickeln\n\nHalte Änderungen lange genug kompatibel, um zu migrieren:\n\n- Versioniere Schemata oder Payloads (v1, v2), sodass Alt und Neu koexistieren können.\n- Führe eine Kompatibilitätsphase, in der alte und neue Felder gleichzeitig vorhanden sind.\n- Backfille, bevor du Logik umschaltest, die vom neuen Shape abhängt.\n- Entferne Felder erst, nachdem du bestätigt hast, dass nichts mehr darauf zugreift.\n\n### Wo Mappings brechen\n\nDie meisten echten Fehler passieren in der Verbindung zwischen Systemen. Beispiel: Dein ETL joined orders mit customers über customer_id. Wird es in client_id umbenannt, kann der Join in Null-Matches kippen und trotzdem Zeilen produzieren.\n\nAchte auf fragile Stellen: Typumwandlungen, Joins, die Schlüssel als unveränderlich annehmen, und Downstream-Regeln wie „Status ist einer dieser Werte“.\n\n## Sicherheit und Ownership: wer darf was synchronisieren?\n\nSicherheitsfragen sehen in beiden Ansätzen ähnlich aus, aber Risiken treten an unterschiedlichen Stellen auf. Replikation läuft oft kontinuierlich mit breitem Leserechte-Zugriff auf Änderungen. Batch-ETL zieht nach Plan größere Datenmengen auf einmal. In beiden Fällen gilt: gib so wenig Rechte wie nötig.\n\nNutze ein dediziertes Service-Konto, nicht das Login einer Person. Erteile read-only-Zugriff nur auf die Tabellen, Spalten oder Views, die nötig sind, und beschränke, von wo aus sich verbunden werden kann. Wenn möglich, biete eine dedizierte "Sync-View" an, die Daten filtert, die das Ziel nie sehen soll.\n\nSensitive Felder überraschen Teams oft. Selbst wenn das Ziel einen Datensatz braucht, muss es nicht alles davon sehen. Entscheide früh, ob Kontaktangaben, Zahlungsinfos oder interne Notizen weggelassen, maskiert oder tokenisiert werden. Verschlüssele Daten in Transit und bewahre Secrets in einem richtigen Secret-Store, nicht in Pipeline-Konfigurationen, auf.\n\nOwnership verhindert endlose Diskussionen später:\n\n- Wähle eine Source of Truth pro Feld (nicht nur pro Tabelle).\n- Lege fest, ob das Ziel zurückschreiben darf.\n- Entscheide, wie Konflikte gelöst werden (Last Write Wins, Zieländerungen ignorieren, manuelle Prüfung).\n- Setze Aufbewahrungsregeln für kopierte Daten im Ziel.\n\nAudit ist das letzte Stück Vertrauen. Du solltest beantworten können: wer hat die Daten gesehen, was hat sich geändert und wann sind die Daten gelandet. Eine einfache Praxis ist, eine nachvollziehbare Sync-Run-ID und Zeitstempel mitzuführen, damit ein Update end-to-end verfolgt werden kann.\n\n## Was du überwachen solltest, damit der Sync vertrauenswürdig bleibt\n\nEin Sync ist nur nützlich, wenn du ihm an einem beliebigen Dienstag vertraust. Unabhängig vom Ansatz sollte Monitoring zeigen, wie weit ihr hinten seid, wie oft ihr ausfallt und ob die Zahlen noch Sinn machen.\n\nDrei tägliche Gesundheits-Signale:\n\n- Lag/Latenz: wie weit das Ziel hinter der Quelle ist\n- Fehlerquote: Fehler, Retries und in einen Dead-Letter geschickte Zeilen\n- Durchsatz: Zeilen oder Events pro Minute und plötzliche Einbrüche Richtung Null\n\nDann füge einige Datenqualitätsprüfungen hinzu, die stille Probleme erwischen. Wähle ein paar wichtige Tabellen (Bestellungen, Rechnungen, Tickets) und validiere sie reproduzierbar. Wenn die Quelle gestern 1.240 Bestellungen hatte, sollte das Ziel nicht 1.180 haben, außer du kennst den Grund.\n\nPrüfungen, die oft viel abdecken:\n\n- Zeilenzählungen pro Tag (oder Stunde für kritische Feeds)\n- Matching-Summen (Summe der Beträge, Anzahl bezahlter Bestellungen)\n- Null-Rate bei Pflichtfeldern (E-Mail, Status, Zeitstempel)\n- Eindeutigkeit von Schlüsseln (keine doppelten order_id)\n- "Delete-Truth": gelöschte oder stornierte Datensätze verschwinden auch downstream (oder werden markiert)\n\nKonsistenzprobleme verstecken sich oft in den Lücken: spät ankommende Updates, fehlende Deletes oder out-of-order angewendete Events. Verfolge den ältesten unverarbeiteten Zeitstempel und prüfe regelmäßig Stichproben, um zu bestätigen, dass die neueste Version vorhanden ist.\n\nBeim Alerting: halte es langweilig und handlungsfähig. Setze Schwellenwerte (z. B. Lag über 15 Minuten, Fehlerquote über 1 %, Durchsatz unter Baseline für 10 Minuten) und pflege ein Runbook, das beantwortet: was zuerst prüfen, wie sicher wiederholen und wie bestätigen, dass alles wieder korrekt ist.\n\n## Schritt-für-Schritt: wie du den richtigen Sync-Ansatz wählst\n\nSei klar darüber, wer die Daten nutzt. Ein Finanzreport, ein Support-Dashboard und eine automatisierte Preisregel greifen zwar auf dieselben Tabellen zu, haben aber unterschiedliche Anforderungen. Wenn Entscheidungen zeitkritisch sind, sind verspätete Daten nicht nur nervig — sie können falsch machen.\n\nEin einfacher Entscheidungsprozess:\n\n1. Name die Konsumenten und ihre Entscheidungen. Liste Bildschirme, Reports und Prozesse auf, die vom Sync abhängen, und was sie beeinflussen.\n2. Setze Ziele, keine vagen Aussagen. Vereinbare Frische (Sekunden, Minuten, Stunden), Korrektheit (welche Fehler sind akzeptabel) und Kosten (Infrastruktur, Engineering-Zeit, Betriebsaufwand).\n3. Wähle das einfachste Muster, das die Ziele erfüllt. Nutze Replikation, wenn du nahezu Echtzeit und vorhersehbare Change-Capture brauchst. Nutze Micro-Batches, wenn "alle paar Minuten" reicht. Nutze nächtliche Batches für Reporting und historische Snapshots. Hybride Lösungen sind üblich.\n4. Plane die Wiederherstellung. Entscheide, wie weit zurück du replayen kannst, wie ein Backfill läuft und wie Loads idempotent bleiben.\n5. Definiere Vertrauensprüfungen und Ownership. Wähle Validierungen, die Gesundheit beweisen (Counts, Summen, last-updated-Zeit, Stichproben) und nenne, wer paged wird und wer Daten repariert.\n\nKonkretes Beispiel: Wenn Support den Bestellstatus im Gespräch mit einem Kunden braucht, zählen Minuten — Replikation oder Micro-Batch passen. Wenn Finance tägliche Umsatzzahlen braucht, reicht oft ein nächtlicher Batch.\n\n## Häufige Fehler, die synchronisierte Daten unzuverlässig machen\n\nDie größte Falle ist anzunehmen, dass "frische" Daten automatisch "richtige" Daten sind. Eine Pipeline kann Sekunden alt sein und trotzdem falsch, weil ein Join sich geändert hat, ein Filter hinzugefügt wurde oder eine Zeile dupliziert wurde. Ohne Validierung bemerkst du das oft erst, wenn ein Dashboard seltsam aussieht oder ein Kunde sich beschwert.\n\nDeletes sind ein weiterer häufiger Fehlerpunkt. Beide Ansätze brauchen einen klaren Plan, was "entfernt" bedeutet. Wenn System A hard-deleted, System B aber nur insertet und updated, driften Reports über die Zeit. Soft-Deletes sind genauso tückisch, wenn der Sync das Delete-Flag und den Zeitstempel nicht mitträgt.\n\nWiederkehrende Fehler:\n\n- Frische als Hauptziel behandeln und grundlegende Counts, Summen und Stichprüfungen überspringen\n- Inserts und Updates syncen, aber keine Deletes, Merges oder Deaktivierungszustände\n- Feld-Mappings hard-coden, die bei Umbenennungen oder Typänderungen stillschweigend brechen\n- Keine Backfill-Strategie bei notwendigen historischen Korrekturen\n- Alerts nur bei Job-Fehlern, nicht bei Lag, fehlenden Daten oder langsamem Drift\n\nBeispiel: Dein CRM markiert einen Kunden als "inactive" statt ihn zu löschen. Dein ETL kopiert nur Kunden mit status = active. Einen Monat später sehen Umsatzberichte gut aus, aber Retention-Metriken sind verzerrt, weil inaktive Kunden nie migriert oder entfernt wurden. Alles sah frisch aus, aber die Korrektheit war schon lange falsch.\n\n## Schnelle Checkliste, bevor du den Sync als „fertig“ erklärst\n\nVereinbare „fertig“ in klaren Zahlen, eindeutiger Ownership und getesteter Wiederherstellung. Ein Sync, der am ersten Tag gut aussieht, kann driften, sobald echte Änderungen und echte Fehler auftreten.\n\n- Frische-Versprechen ist dokumentiert. Definiere die Ziel-Verzögerung, wann sie gemessen wird und was passiert, wenn das Ziel verfehlt wird.\n- Source of Truth ist explizit. Dokumentiere für Schlüsselfelder (Status, Preis, Kunden-E-Mail), welches System gilt und ob Updates ein- oder zweiseitig sind.\n- Wiederherstellung ist end-to-end getestet. Simuliere einen Ausfall und bestätige, dass du ohne Duplikate oder fehlende Zeilen replayen kannst.\n- Regeln für Schema-Änderungen existieren. Entscheide, wer Änderungen genehmigt, wie sie eingerollt werden und wie Umbenennungen, Typänderungen und entfernte Spalten gehandhabt werden.\n- Monitoring ist handlungsfähig. Überwache Lag, Fehlerquote und Kern-Datenprüfungen mit Alerts, die einer on-call-Person sagen, was als Nächstes zu tun ist.\n\nReality-Check: Wenn delivery_instructions zu Bestellungen hinzugefügt wird, sollte dein Prozess klar machen, ob es automatisch synchronisiert wird, laut fehlschlägt oder sicher ignoriert wird.\n\n## Ein realistisches Beispiel: Bestellungen zwischen zwei Systemen synchronisieren\n\nStell dir ein Unternehmen vor, das Bestellungen in PostgreSQL speichert. Zwei Teams brauchen diese Daten: Support braucht ein Live-Dashboard für "Wo ist meine Bestellung?", und Finance braucht stabile tägliche Zahlen für Abschluss und Reporting.\n\nSie verwenden einen gemischten Ansatz statt ein Werkzeug für alles zu zwingen.\n\nFür Support nutzen sie logische Replikation, damit neue Bestellungen und Status-Updates schnell in einer read-optimierten Datenbank erscheinen, die das Dashboard antreibt. Für Finance läuft einmal täglich nach Geschäftsschluss ein Batch-ETL, das finale Bestellungen ins Reporting-Warehouse lädt, Geschäftregeln anwendet (Steuern, Rabatte, Rückerstattungen) und einen täglichen Snapshot erzeugt, der sich nicht verändert.\n\nDann passiert eine Schema-Änderung: Das Produktteam fügt refund_reason hinzu. Support will es sofort. Replikation kann die neue Spalte schnell durchreichen, während der Batch-Job sie zunächst optional behandelt (Default "unknown"), bis die Reporting-Logik fertig ist.\n\nEines Tages ist das Support-Ziel 3 Stunden down. Als es zurückkommt, holt die Replikation Änderungen aus der gespeicherten Position nach. Der wichtige Schritt ist nicht nur "es lief weiter", sondern "es ist korrekt": Sie prüfen die Bestellzahlen für das Ausfallfenster und führen Stichproben einiger neuer Bestellungen End-to-End durch.\n\nJeden Morgen prüfen sie eine kurze Signalliste, bevor sie den Zahlen vertrauen: Replikations-Lag, Quelle vs Ziel Bestellzahlen der letzten 24 Stunden, Duplikate in Finance-Tabellen, erfolgreicher Batch-Lauf plus geladene Zeilen pro Ausführung und Stichproben hochpreisiger Bestellungen, die in beiden Systemen abgeglichen werden.\n\n## Nächste Schritte: Sync sichtbar und bedienbar machen\n\nNachdem du einen Ansatz (oder Hybrid) gewählt hast, ist die eigentliche Arbeit, den Sync so zu gestalten, dass Menschen ihm täglich vertrauen. Wähle ein messbares Ziel und behandle es wie eine Produktmetrik. Für die meisten Teams ist das erste Ziel entweder Frische (wie neu sind die Daten) oder Genauigkeit (wie oft sind sie falsch).\n\nFange klein an: eine Tabelle, einen Event-Stream oder einen Workflow, der zählt (z. B. Bestellungen oder Tickets). Stabilisiere diesen Pfad, dann kopiere das Muster. Vorzeitig zu expandieren, bevor du Probleme schnell erkennen und beheben kannst, erzeugt schneller eine größere Unordnung.\n\nEine praktische "Sync-Status"-Ansicht für nicht-technische Teams enthält üblicherweise aktuellen Lag vs Ziel, letztes erfolgreiches Sync-Zeit, letzter fehlgeschlagener Versuch, heute verarbeitete Menge vs erwarteter Bereich und eine kurze Anweisung, was zu tun ist, wenn der Status rot ist.\n\nWenn du interne Admin-Screens schnell bauen möchtest, kann eine No-Code-Plattform wie AppMaster (appmaster.io) dir helfen, eine Monitoring-Ansicht zu liefern und sie anzupassen, ohne alles neu zu schreiben, wenn Schema oder Workflow sich ändern.