Sistemlər arasında dublikat: idempotentlik və xarici ID

Qısa cavab

Sistemlər arasında dublikat məlumatın qarşısı beş texniki qayda ilə alınır: hər qeydin mənbə sistemdəki identifikatorunu (xarici ID) hədəf sistemdə saxlamaq, yeni qeyd yaratmaq əvəzinə «varsa yenilə, yoxsa yarat» (upsert) əməliyyatı etmək, hər hadisəyə unikal idempotentlik açarı vermək ki, təkrar göndəriş ikinci qeyd yaratmasın, iki tərəfli sinxronizasiyada dəyişikliyin haradan gəldiyini işarələmək ki, sonsuz dövrə yaranmasın, və müntəzəm tutuşdurma hesabatı. Bu qaydalar biznes dublikatlarını — eyni adamın üç kanaldan yazmasını — həll etmir; onlar sistemlərin özünün yaratdığı dublikatlara qarşıdır.

İki növ dublikat

Birinci növ biznes dublikatıdır: eyni müştəri Instagram-dan və WhatsApp-dan yazır və iki kart yaranır. Bunun qarşısını qəbul qaydaları alır — onları dublikat lead-lərin qarşısını almaq yazısında izah etmişik. İkinci növ texniki dublikatdır: bir müraciət bir dəfə gəlib, amma inteqrasiya onu hədəf sistemdə iki dəfə yaradıb. Bu yazı ikinci növ haqqındadır.

Texniki dublikat daha təhlükəlidir, çünki görünməzdir: biznes tərəfi «müştəri iki dəfə yazıb» düşünür, halbuki problem inteqrasiyadadır və hər gün təkrarlanır.

Texniki dublikat haradan gəlir

• Təkrar göndəriş: göndərən cavab almadı, eyni hadisəni yenidən göndərdi, qəbul edən isə ikisini də yaratdı.
• İki tərəfli sinxron dövrəsi: A sistemi B-ni yeniləyir, B dəyişikliyi A-ya «yeni» kimi qaytarır, A yenidən göndərir.
• Paralel idxal: eyni fayl iki dəfə və ya iki nəfər tərəfindən yüklənir.
• Ortaq açarın olmaması: hədəf sistem gələn qeydin əvvəl gəlib-gəlmədiyini bilmir.
• Eyni anda iki proses: iki işçi eyni hadisəni eyni anda emal edir.

Qayda 1: xarici ID

Hər qeyd hədəf sistemə gələndə mənbə sistemdəki identifikatoru ayrıca sahədə saxlanılır: «mənbə: çat platforması, ID: 48213». Növbəti dəfə eyni ID gələndə hədəf sistem yeni qeyd yaratmır, mövcudunu tapır. Telefon və e-poçt da açar ola bilər, amma onlar dəyişir; xarici ID isə dəyişmir. Ən etibarlı yol ikisini birlikdə istifadə etməkdir: xarici ID əsas açar, telefon isə ehtiyat yoxlama.

Qayda 2: upsert

«Yarat» əməliyyatı əvəzinə «varsa yenilə, yoxsa yarat» əməliyyatı istifadə olunur. Hədəf sistem əvvəlcə açara görə axtarır: qeyd varsa, onu yeniləyir; yoxdursa, yaradır. Bir çox CRM bu əməliyyatı hazır təklif edir — məsələn, HubSpot idxalda eyni e-poçtlu kontaktı yenisini yaratmadan yeniləyir. Upsert olmadan hər təkrar göndəriş yeni qeyd deməkdir.

Qayda 3: idempotentlik açarı

İdempotentlik o deməkdir ki, eyni əməliyyatı bir dəfə də, beş dəfə də etmək eyni nəticəni verir. Bunun üçün hər hadisəyə unikal açar verilir — məsələn, hadisənin ID-si. Qəbul edən sistem son müddətdə emal etdiyi açarları yadda saxlayır və eyni açar yenidən gələndə əməliyyatı təkrar etmir, sadəcə «artıq emal olunub» cavabı verir. Webhook-ların təkrar göndərilməsi barədə webhook nədir yazısında ətraflı danışmışıq.

Qayda 4: sinxron dövrəsinin qarşısı

İki tərəfli sinxronizasiyada hər dəyişikliyə onun mənbəyi yazılır: «bu dəyişiklik B sistemindən gəlib». A sistemi B-dən gələn dəyişikliyi qəbul edəndə onu yenidən B-yə göndərmir. Bundan əlavə, hər sahənin bir «sahibi» olmalıdır — yalnız bir sistem həmin sahəni dəyişə bilər, digəri oxuyur. Sahə sahibliyini CRM data mapping checklisti yazısında izah etmişik.

Qayda 5: tutuşdurma hesabatı

Ən yaxşı qaydalar da hər halı tutmur, ona görə müntəzəm yoxlama lazımdır. Həftədə bir dəfə iki sistemin saylarını müqayisə edin: mənbədə bu həftə neçə lead yaranıb, hədəfdə neçə. Fərq varsa — çox və ya az — səbəbi araşdırılır. Hədəfdə eyni xarici ID ilə iki qeyd tapılırsa, bu, qaydalardan birinin işləmədiyinin birbaşa sübutudur.

İllüstrativ nümunə

Bu, illüstrativ nümunədir. Onlayn mağaza çat platformasından lead-ləri CRM-ə webhook ilə ötürür. Satış rəhbəri fərq edir ki, bəzi müştərilər CRM-də iki dəfə görünür. Araşdırma göstərir ki, CRM bəzən cavabı gecikdirir, çat platforması cavab almayanda hadisəni yenidən göndərir, CRM isə hər ikisini yeni lead kimi yaradır.

Düzəliş: CRM-də «xarici ID» sahəsi açılır, inteqrasiya «yarat» əvəzinə upsert istifadə edir, qəbul edən tərəf isə emal olunan hadisə ID-lərini 24 saat yadda saxlayır. Həftəlik tutuşdurma hesabatı fərqin sıfıra endiyini göstərir.

Tipik səhvlər

• Texniki dublikatı «müştəri iki dəfə yazıb» saymaq.
• Yalnız ada görə uyğunlaşdırmaq.
• Təkrar cəhd qurub idempotentlik qurmamaq.
• Hər sahəni iki tərəfli sinxronizasiya etmək.
• Dublikatları əl ilə silib səbəbi düzəltməmək — sabah yenə yaranır.

Məhdudiyyətlər

Bu qaydalar hər iki sistemin imkanlarından asılıdır: hədəf sistem upsert və ya xarici ID sahəsini dəstəkləmirsə, ara xidmət lazım ola bilər. Mövcud dublikatların təmizlənməsi ayrıca işdir — onu CRM-də dublikat kartlar yazısında izah etmişik. Çox sistemli mühitdə tam sinxronluq nadir hallarda mümkündür, ona görə tutuşdurma hesabatı daimi olmalıdır.

Kim cavabdehdir

Texniki dublikatların sahibi inteqrasiyanın sahibidir — adətən IT və ya inteqrasiyanı quran tərəf. Biznes istifadəçiləri dublikatı görəndə onu silməməli, inteqrasiya sahibinə bildirməlidir: hər dublikat səbəbin tapılması üçün sübutdur. Tutuşdurma hesabatı da inteqrasiya sahibinə gedir və fərq olanda kimin araşdırdığı əvvəlcədən yazılır.

Vexvon-da dublikatlar

Vexvon-da eyni şirkətdə eyni nömrə ilə açıq lead varsa, yeni lead dublikat kimi ona bağlanır; CSV idxalında təkrar nömrələr yükləmə zamanı yoxlanılır; avtomatik zəng qaydalarında isə şirkət üzrə dedupe pəncərəsi var. Kanallardan gələn webhook-ların statusu izlənir və uğursuz qalanlar yenidən işlənir. Vexvon-dan şirkətin sisteminə gedən webhook-lar üçün qəbul tərəfində upsert və idempotentlik qaydasını inteqrasiya planında birlikdə razılaşdırırıq. Ətraflı: inteqrasiyalar.

Növbəti addım

Hədəf sisteminizdə bir sorğu işlədin: eyni telefon və ya eyni mənbə ID-si ilə neçə qeyd var və onlar bir-birindən neçə saniyə arayla yaranıb? Bir neçə saniyəlik fərq texniki dublikatın əlamətidir. Digər yazılar enterprise inteqrasiya bölməsindədir; inteqrasiyanızı demo zamanı birlikdə yoxlaya bilərik.