Veri Senkronizasyonu: Tek Yön mü, Çift Yön mü?

Veri senkronizasyonu, kurumsal projelerde en çok küçümsenen iş kalemi. Talep genellikle tek cümleyle geliyor: "ERP'deki müşteri bilgileri CRM'de de görünsün." Tahmin bir hafta, gerçekleşen üç ay; aradaki farkın tamamı, ilk gün sorulmayan bir soruda gizli: aynı kayıt iki yerde birden değişirse ne olacak?

Önce yön, sonra teknoloji

Hangi kuyruk, hangi format, hangi zamanlayıcı — bunların hepsi ikincil. Birincil karar şudur: her veri alanı için tek bir kaynak sistem (system of record) belirlenmiş midir?

Bu soru "hangi sistem daha önemli" diye sorulduğunda cevapsız kalır, ama alan bazında sorulduğunda kolayca cevaplanır:

Bu tablo doldurulduğunda, "çift yön" diye başlayan pek çok proje aslında birkaç tek yönlü akışa dönüşüyor. Bu, hem geliştirmesi hem hata ayıklaması kat kat kolay bir yapı.

Tek yön: varsayılan tercih

Tek yönlü akışta bir taraf yazar, diğer taraf okur. Hedef sistemde o alan salt okunur hâle getirilir; kullanıcı düzenlemeye çalıştığında "bu bilgi ERP'den gelir" uyarısı görür.

Bu kısıtlama teknik bir tembellik değil, kasıtlı bir tasarım. Alanı hedefte düzenlenebilir bırakırsanız kullanıcı er ya da geç düzenler, bir sonraki senkronizasyon değişikliği ezer ve kullanıcı sisteme güvenmeyi bırakır. "Yazdığım kayboluyor" şikâyetinin arkasında neredeyse her zaman bu vardır.

Çift yön gerçekten gerekiyorsa

Bazı durumlarda kaçınılmaz: saha ekibi mobil uygulamadan müşteri adresini güncelliyor, muhasebe aynı adresi ERP'den düzeltiyor. Böyle bir durumda üç şeyi baştan yazmanız gerekir.

1. Her kayıtta değişiklik damgası ve kaynak. Hangi sistemde, ne zaman değiştiğini bilmeden çakışmayı çözemezsiniz.

ALTER TABLE musteri
  ADD kaynak_sistem  VARCHAR(20)  NOT NULL DEFAULT 'yerel',
  ADD dis_id         VARCHAR(64)  NULL,
  ADD dis_surum      VARCHAR(64)  NULL,   -- karşı sistemin sürüm/etag değeri
  ADD son_senk_at    DATETIME     NULL,
  ADD UNIQUE KEY uq_dis (kaynak_sistem, dis_id);

2. Çakışma kuralı. "Son yazan kazanır" cazip ama tehlikelidir; iki sunucunun saati birkaç saniye kayıksa veya bir mesaj gecikirse eski veri yenisini ezer. Alan bazında sahiplik tanımlayabiliyorsanız en iyisi odur. Tanımlayamıyorsanız, çakışan kaydı otomatik çözmek yerine bir inceleme kuyruğuna almak çoğu kurumda daha az zarar veriyor — sessizce yanlış veri üretmektense birkaç kaydı insanın çözmesi tercih edilir.

3. Döngü koruması. Çift yönlü kurgunun klasik hatası: A'dan gelen değişiklik B'ye yazılır, B bunu kendi değişikliği sanıp A'ya geri gönderir, sonsuz döngü başlar. Çözüm, senkronizasyon kaynaklı yazma işlemlerini işaretleyip bu işaretli değişiklikler için olay yayınlamamaktır.

Tetikleme: zamanlayıcı mı, olay mı?

Karşı sistem olay yayınlayabiliyorsa (webhook) tercih edilecek yol budur: değişiklik anında akar, gecikme saniyelerle ölçülür. Webhook uçlarını tasarlarken düşülen tuzaklar için webhook tasarımı yazısına göz atın.

Olay yayınlanamıyorsa artımlı çekme yapın: "son senkronizasyondan sonra değişenleri ver". Tam kopyalama (full sync) günlük rutin olmamalı; yalnızca elle tetiklenen bir kurtarma yolu olarak dursun. Binlerce kaydı her gece baştan yazmak, hem karşı sistemi yorar hem de gerçek bir değişikliği fark etmenizi imkânsızlaştırır.

Aynı mesaj iki kez gelirse

Gelecektir. Ağ koptuğunda gönderen taraf tekrar dener, yanıtı alamadığı için aynı mesajı yeniden yollar. Alıcı taraf buna hazır değilse mükerrer kayıt üretir.

Çözüm, her mesaja benzersiz bir anahtar koymak ve alıcıda bu anahtarı kaydetmektir:

// Aynı olayı ikinci kez işleme
if ($this->islenmisOlaylar->where('olay_anahtari', $olay['id'])->countAllResults() > 0) {
    return $this->response->setStatusCode(200)->setJSON(['durum' => 'zaten_islendi']);
}

$this->db->transStart();
$this->musteriGuncelle($olay['veri']);
$this->islenmisOlaylar->insert(['olay_anahtari' => $olay['id'], 'islendi_at' => date('Y-m-d H:i:s')]);
$this->db->transComplete();

Dikkat: yinelenen mesaja hata değil, başarı dönün. Hata dönerseniz gönderen taraf tekrar dener ve sonsuz döngüye girersiniz. Dayanıklılık desenlerinin tamamı için üçüncü parti API entegrasyonunda dayanıklılık yazısı iyi bir başvuru.

İzlenebilirlik olmadan bakım imkânsız

Senkronizasyonun en çok zaman yiyen tarafı geliştirme değil, "bu müşteri neden güncellenmemiş" sorusuna cevap aramak. Bunu ucuzlatan tek şey kayıt tutmak: hangi kayıt, hangi yönde, ne zaman, hangi sonuçla işlendi. Bu kayıtları tutan ekipler soruyu dakikalar içinde kapatıyor; tutmayanlar her seferinde iki sistemi elle karşılaştırıyor. Nasıl kurgulanacağı için denetim izi yazısına bakabilirsiniz.

Sonuç

Veri senkronizasyonu projelerinde teknoloji seçimi nadiren belirleyicidir; belirleyici olan, ilk gün doldurulan o basit alan-yön tablosudur. Her alan için tek bir kaynak belirleyin, mümkün olan her yeri tek yöne indirin, çift yön kaçınılmazsa çakışma kuralını yazmadan koda başlamayın ve her mesajı tekrar gönderilebilir varsayın. Bu dört madde, üç aylık projeleri üç haftaya indiriyor. Entegrasyonun sözleşme tarafı için REST API tasarımı yazısı tamamlayıcı olacaktır.

Kurumsal entegrasyon desenlerinin klasik kaynağı: Enterprise Integration Patterns.