Datenpipelines mit einem Wiederherstellungsweg

Das Problem

Wiederholungen helfen nur, wenn sie keine Duplikate erzeugen. Diese Referenzarchitektur trennt Aufnahme und Transformation für einen vorhersehbaren Wiederherstellungsweg. Die Kennzahlen sind geplante Ziele, keine Produktionsmessungen.

Das System

Unveränderliche Rohdaten-Batches bilden die Grenze für eine erneute Verarbeitung. Schema, Eindeutigkeit und Aktualität vor der Veröffentlichung prüfen. Fehlerhafte Datensätze isolieren, statt sie still zu verwerfen.

Idempotenz als Vertrag

Eine stabile Quell-ID und Version als Deduplizierungsschlüssel verwenden. Checkpoints erst nach dem Commit der Zieltransaktion speichern. Ein Absturz zwischen Commit und Checkpoint muss bei einer Wiederholung dasselbe Ergebnis liefern.

INSERT INTO events (source_id, source_version, payload)
VALUES ($1, $2, $3)
ON CONFLICT (source_id, source_version) DO NOTHING;

Dafür ist ein Unique Constraint auf (source_id, source_version) erforderlich. Quellversionen müssen unveränderlich sein; veränderliche Datensätze benötigen eine explizite Update-Strategie.

Betrieb

Batch-Alter, Anzahl abgelehnter Zeilen und Zeitpunkt der letzten erfolgreichen Veröffentlichung erfassen. Auf die für Nutzer relevante Aktualität alarmieren, nicht auf jeden Retry. Ein hilfreicher Alarm verlinkt den betroffenen Batch und die Anleitung zur Wiederverarbeitung.

Abwägungen

Rohdaten-Aufbewahrung kostet Speicher und braucht ein Löschkonzept. Batch-Verarbeitung akzeptiert begrenzte Latenz zugunsten einfacherer Wiederherstellung. Streaming erst einführen, wenn die Latenzanforderungen den Betriebsaufwand rechtfertigen.