ERP entegrasyonunda veri tutarlılığı: kuyruk mimarisi rehberi

Neden doğrudan çağrı yetmez

Vitrinin her tıklamada ERP’yi senkron sorması, stok bitişini gecikmeli gösterir ve fatura numarasını çift üretir. Kurumsal sipariş portallarında gördüğümüz en pahalı hata budur: kullanıcı “stok var” diye onaylar, ERP üç saniye sonra reddeder. Doğrudan çağrı, hata anında kullanıcıyı ve muhasebeyi aynı anda cezalandırır.

Doğru model olaydır. Sipariş oluştu, stok rezerve edildi, fatura kesildi — her biri kuyruğa yazılır. Tüketici idempotent olur; aynı olay iki kez gelse sonuç değişmez. Outbox tablosu, işlemi ve mesajı aynı veritabanı transaction’ında tutar; “kaydettim ama kuyruk düşmedi” boşluğunu kapatır.

Kuyruk sözleşmesi

Her mesaja correlation id, her hataya ölü mektup kuyruğu koyun. Yeniden deneme politikasını sınırsız bırakmayın: 5 deneme, üstel bekleme, sonra insan. Stok ve fiyat gibi sık değişen alanları olayın içinde dondurun; tüketici “şu anki fiyatı sorayım” derse tutarlılık biter.

B2B portallarda sipariş kalemi, sevkiyat ve e‑fatura üç ayrı projeksiyondur. Tek bir “sipariş tablosu” her raporu cevaplamaz. Okuma modelini yazma modelinden ayırın. ERP bir kaynak gerçekliği, vitrin bir başka; ikisini uzlaştıran iş gece çalışır ve sapmayı metrik olarak raporlar.

• Outbox + en az bir kez teslimat.
• Idempotency anahtarı: sipariş no + olay tipi.
• Ölü mektup ve alarm aynı panoda.
• Uzlaşma işi: gece, satır satır, fark listesi.

Saha örneği

Ege Tekstil bayi portalında sipariş süresi 11 dakikadan 4 dakikaya indi çünkü vitrin ERP timeout’unu beklemiyor. Kullanıcı onay ekranını görür; rezervasyon asenkron tamamlanır. Stok sapması ilk ayda binde ikiydi, uzlaşma işi bunu görünür kıldı. Görünür sapma, gizli sapmadan iyidir.

Fatura tarafında e‑belge sağlayıcısı bazen 30 saniye döner. Bunu HTTP isteğinin içinde beklemek sepeti kilitler. Fatura olayını ayrı kuyruğa alın, kullanıcıya “belge hazır olunca e‑posta” deyin. Muhasebe belgenin varlığını panelden izler; vitrin mutlu yolunu kaybetmez.

Varyant ve birim çevrimleri kuyruk sözleşmesine yazılmadan canlıya çıkmayın. ERP “adet”, vitrin “koli” konuşuyorsa stok projeksiyonu bir gece içinde sapar. Çevrim tablosunu olayın yanında versiyonlayın; sessiz değişen birim, en zor bulunan bug’dır. Aynı şekilde vergi dairesi, e‑fatura senaryosu ve iade hareketi ayrı olay tipleridir — hepsini “sipariş güncellendi” çuvalına atmayın.

Kapasite planı kuyruk derinliğine bakarak yapılır, CPU grafiğine değil. Bayi kampanyası sabah 09:00’da açıldığında üretici on bin olay basar; tüketici sayısı sabitse ölü mektup değil, gecikme birikir. O gecikme stokta “var” gösterir. Otomatik ölçek, tüketici için; üretici için backpressure. İkisini karıştırmayın.

Geliştirici ortamında kuyruğu bellek içi sahte bir bus ile geçiştirmeyin. Kontratı (şema, zorunlu alan, idempotency) aynı serializer ile test edin. Şema evrimi için ek alanlar isteğe bağlı başlar, kaldırılan alanlar en az bir çeyrek yaşar. Aksi halde eski tüketici yeni olayı yutar ve sessizce yanlış yazar.

Gözlemlenebilirlik

Log’a sipariş no, bayi kodu ve olay tipini yazın. Dağıtık iz (trace) yoksa bile bu üçlü, sabahki sapma toplantısını 40 dakikadan 8 dakikaya indirir. Kuyruk derinliği, tüketici gecikmesi ve ölü mektup adedi üç kırmızı göstergedir. Biri eşik aşınca geliştirici değil, nöbetçi uyanır.

Test ortamında ERP’nin yavaş ve hata üreten bir ikizini koşturun. Mutlu yol testi entegrasyonu doğrulamaz. “Stok 0 iken sipariş”, “aynı sipariş iki kez”, “fatura timeout” senaryoları olmadan canlıya çıkmayın. Bu üçü, son iki yıldaki kesintilerimizin çoğunun özeti.

Sonuç

ERP entegrasyonu bir form API’si değildir; bir olay sistemi kurmaktır. Kuyruk, outbox ve uzlaşma olmadan veri tutarlılığı vaadi boş kalır. Kapasiteyi artırmadan önce sözleşmeyi yazın: kim kaynak gerçekliği, kim projeksiyon, kim insan müdahalesi. Bu cümleler netse kod da netleşir.

Yayın öncesi kontrol

Canlıya çıkmadan bir gün önce üretici ve tüketici versiyonlarını, şema numarasını ve ölü mektup alarmını aynı ekranda görün. “Testte geçti” cümlesi, kampanya sabahı kuyruk derinliği için yeterli değildir. Bayi kodu olmayan olayları bilinçli olarak düşürün; gürültü, gerçek sapmayı gizler. Nöbetçi runbook’u üç komuttan uzun olmasın: durdur, tekrar oku, insan çağır.

Sözleşmeyi müşteri teknik ekibiyle de imzalayın. Kim kaynak gerçekliği, kim izleyici, kim manuel düzeltme yetkisi. Bu üç rol karışırsa gece uzlaşması gündüz kavgaya döner. Vexria teslimlerinde bu belge proje klasörünün ilk sayfasıdır; kod ikinci. Outbox satırının silinmesi, “temizlik” değil olay kaybıdır.

Kuyruk yaşını p95 olarak izleyin. Ortalama yeşilken kuyruğun kuyruğu kırmızı olabilir. Beş dakikayı aşan sipariş olayı nöbetçiyi uyandırır; “biraz geç oldu” SLA değildir. Eşiği müşteriyle yazın ve dashboard’da aynı cümleyle gösterin. Kampanya günü eşiği gevşetmek, sapmayı meşrulaştırır.

Uzlaşma işini gece yarısı sessiz çalıştırmayın: sapma raporu sabah ilk toplantının tek slaydı olsun. Stok eksiye düştüyse vitrini kapatmak kahramanlıktır; kaynağı düzeltmek iştir. İki gün üst üste aynı SKU sapıyorsa tüketici değil üretici şüphelidir.

• Şema sürümü üretici ve tüketici logunda aynı mı?
• Ölü mektup kuyruğu boş mu, yoksa “sonra bakarız” mı?
• Manuel düzeltme yetkisi tek kişide mi, denetim izi var mı?
• Kampanya runbook’u üç komuttan uzun mu?