Change Data Capture (CDC): przechwytywanie zmian danych

Change Data Capture, w skrócie CDC, to wzorzec techniczny służący do przechwytywania zmian w danych źródłowych. Gdy w bazie powstaje nowy rekord, zmienia się status klienta albo rekord zostaje usunięty, CDC publikuje zdarzenie opisujące tę zmianę. Odbiorca może na jego podstawie zaktualizować drugi system. Różnica względem nocnego eksportu CSV jest prosta: zamiast za każdym razem przenosić pełny zbiór, przesyłasz przyrost. CDC nie jest samą integracją ani webhookiem. Jest mechanizmem, który wiarygodnie zauważa zmianę w miejscu, gdzie dane faktycznie powstały.

Jak działa Change Data Capture?

Najczęściej narzędzie CDC czyta dziennik transakcyjny bazy, na przykład WAL w PostgreSQL lub binlog w MySQL. Z tego dziennika odtwarza zdarzenia insert, update i delete, dodaje metadane takie jak identyfikator transakcji lub pozycja w logu, a następnie przekazuje je do kolejki, usługi integracyjnej albo innej bazy. Inne podejścia wykorzystują znaczniki czasu, osobną tabelę zmian lub triggery. Metoda oparta na logu zwykle mniej ingeruje w aplikację, ale wymaga właściwych uprawnień, konfiguracji retencji logów i monitorowania opóźnienia.

Dlaczego CDC ma znaczenie dla systemu AI?

Agent lub asystent nie powinien odpowiadać na podstawie kopii CRM sprzed tygodnia. Jeśli źródłem prawdy są zamówienia, dostęp do kursu, etapy sprzedaży albo dokumenty klienta, aktualność ma bezpośredni wpływ na jakość i bezpieczeństwo automatyzacji. CDC może przekazać zmianę do bazy wiedzy, indeksu wyszukiwania, systemu powiadomień albo kolejki do dalszego przetworzenia. Przykład: po zmianie etapu leada na „rozmowa umówiona” zdarzenie może utworzyć checklistę przygotowania spotkania. Nie znaczy to, że AI ma automatycznie wysyłać wiadomości. Krytyczne działania nadal powinny mieć jasne reguły i zatwierdzenie człowieka.

CDC, webhook i okresowy import to nie to samo

Webhook jest komunikatem wysyłanym przez aplikację po konkretnym zdarzeniu, zwykle przez HTTP. CDC działa bliżej warstwy danych i może obserwować zmiany niezależnie od tego, czy producent aplikacji wystawił webhook. Import okresowy odczytuje dane co godzinę lub nocą i porównuje stan, przez co może opóźniać reakcję oraz nie pokazać pełnej historii zmian. CDC bywa źródłem zdarzeń dla webhooków lub workflow, ale nie zastępuje ich całkowicie. Wybór zależy od miejsca, gdzie powstaje prawda o zmianie, wymaganego czasu reakcji oraz ryzyka błędnego działania.

Praktyczny przykład dla eksperta sprzedającego wiedzę

Załóżmy, że płatność za produkt jest zapisana w bazie transakcyjnej, a dostęp do materiałów i komunikacja działają w innych narzędziach. Zamiast codziennie porównywać listy klientów, CDC publikuje zdarzenie po zmianie statusu płatności. Workflow najpierw sprawdza kontrakt danych: identyfikator zamówienia, e-mail, status i czas zmiany. Potem aktualizuje uprawnienie w systemie kursowym oraz tworzy zadanie dla obsługi, jeśli dane są niepełne. Model AI może przygotować spersonalizowany szkic odpowiedzi, ale nie powinien sam rozstrzygać zwrotu, ceny ani dostępu bez reguły biznesowej. Tak zaprojektowany przepływ ogranicza ręczne przepisywanie, nie oddaje decyzji finansowych przypadkowemu promptowi.

Co trzeba zaprojektować przed wdrożeniem?

Najpierw wskaż źródłową tabelę i konkretny cel biznesowy. Potem opisz kontrakt zdarzenia: które pola są wymagane, jak rozpoznać usunięcie, która wersja schematu obowiązuje i gdzie odbiorca zapisuje swój postęp. Zaplanuj idempotencję, bo po awarii odbiorca może dostać to samo zdarzenie więcej niż raz. Ustal też, co dzieje się z rekordem, którego nie da się przetworzyć: nie może zniknąć po cichu. Potrzebujesz kolejki błędów, alertu, metryk opóźnienia i bezpiecznej procedury ponownego przetworzenia. W praktyce warto zacząć od jednego przepływu o ograniczonym ryzyku, a nie od synchronizacji całej firmy.

Ograniczenia, ryzyka i granice obietnicy „na żywo”

CDC nie gwarantuje automatycznie danych w czasie rzeczywistym. Opóźnienie zależy od obciążenia źródła, sieci, kolejki i odbiorcy. Dokumentacja AWS DMS wprost zaznacza, że CDC nie ma gwarantowanego SLA opóźnienia. Zdarzenia mogą zostać powielone podczas odzyskiwania po awarii, dlatego odbiornik musi być odporny na duplikaty. Zmiana schematu, usunięcie kolumny albo zbyt krótka retencja dziennika mogą zatrzymać przepływ. Nie przesyłaj też wszystkich danych tylko dlatego, że są dostępne. Filtruj pola, minimalizuj dane osobowe, ogranicz uprawnienia technicznego konta i testuj automatyzację na danych nieprodukcyjnych, zanim połączysz ją z komunikacją lub płatnościami.