Monolitik ve Noktadan Noktaya (Point-to-Point) Entegrasyonların Sınırları
Geleneksel kurumsal mimarilerde ERP sistemleri (SAP S/4HANA, Microsoft Dynamics 365, Oracle Fusion), organizasyonun tüm operasyonel yükünü merkezileştiren birer “tek gerçeklik kaynağı” (Single Source of Truth) olarak kurgulanmıştır. Ancak kurumların SaaS çözümleri (Salesforce, Workday), lojistik yönetim platformları (WMS), saha servis yazılımları ve B2B e-ticaret portalları ile genişleyen ekosistemi, geleneksel entegrasyon yaklaşımlarını işlevsiz kılmaktadır. Geçmişte sıklıkla tercih edilen noktadan noktaya (Point-to-Point) senkron web servisleri (REST, SOAP) veya doğrudan veritabanı seviyesinde çalışan ETL/ELT batch süreçleri, günümüzün yüksek hacimli ve sıfıra yakın gecikme gerektiren iş modellerinde kritik darboğazlara yol açmaktadır.
Senkron entegrasyonların en büyük handikabı, “sıkı bağımlılık” (tight coupling) ve basamaklı arıza (cascading failure) riskidir. Sipariş girişi yapan bir alt sistemin, ERP’nin mutabakat sürecindeki geçici bir kilitlenme (table/row-level lock) nedeniyle HTTP 504 Gateway Timeout hatası alması, kullanıcı deneyimini ve operasyonel akışı anında felç eder. Benzer şekilde, gecelik çalışan devasa batch işleri de modern 7/24 işleyen global tedarik zincirlerinin veri tazeliği ihtiyacına yanıt verememektedir. Dağıtık veri ambarları, mikroservisler ve hibrit bulut topolojilerinde sürekliliği sağlamak adına modern kurumsal mimarinin tercihi; gevşek bağlı (loosely coupled), yüksek düzeyde ölçeklenebilir ve hata izolasyonuna olanak tanıyan Event-Driven Mimari (EDA) ve Asenkron Veri Senkronizasyonu modelleridir.
Event-Driven Mimaride Temel Tasarım Desenleri
Kurumsal ERP dünyasında bir olayın (event) meydana gelmesi—örneğin bir satınalma siparişinin onaylanması (PurchaseOrderApproved), bir faturanın kesilmesi (InvoicePosted) veya stok rezervasyonunun düşmesi (StockReserved)—iş birimlerinin durum değişikliklerini ifade eder. Bu durum değişikliklerini downstream (tüketici) sistemlere senkronize ederken veri kaybını önlemek ve tutarlılığı korumak adına belirli kurumsal tasarım desenleri (design patterns) zorunludur.
1. Transactional Outbox Pattern
Mikroservisler veya kurumsal uygulamalar, hem kendi ilişkisel veritabanına veri yazıp hem de aynı anda bir mesaj kuyruğuna (message broker) event fırlatmaya çalıştığında “dual-write” problemi ortaya çıkar. Dağıtık İki Fazlı Taahhüt (Two-Phase Commit – 2PC) protokolleri yüksek gecikme ve kilitlenme yarattığı için modern mimarilerde anti-pattern kabul edilir. Bu noktada Transactional Outbox Pattern devreye girer. İşlem sırasında ana tabloya yazılan kayıt ile fırlatılacak event, aynı veritabanı transaction’ı içinde bir outbox tablosuna yazılır. Ayrı bir okuyucu servis (veya CDC aracı), bu outbox tablosunu tarayarak event’leri mesajlaşma platformuna (Apache Kafka, RabbitMQ) iletir ve iletim tamamlandığında kaydı işaretler. Böylece veritabanı işlemi başarılı olurken mesajın kaybolma riski sıfırlanır.
2. Change Data Capture (CDC) ile Olay Yakalama
Eski nesil veya kaynak koduna müdahale edilemeyen ERP çekirdeklerinde Transactional Outbox uygulamak her zaman mümkün olmayabilir. Bu senaryolarda Change Data Capture (CDC) mimarisi devreye girer. Debezium, Kafka Connect veya veritabanlarının yerel Transaction Log madenciliği (Oracle GoldenGate, SQL Server CDC, SAP SLT) mekanizmaları kullanılarak, doğrudan veritabanı işlem günlükleri (WAL / Redo Log) dinlenir. Veritabanı motoruna ek yük getirmeden, satır bazındaki tüm INSERT, UPDATE ve DELETE hareketleri anında yakalanıp bir event akışına (event stream) dönüştürülür.
3. Dağıtık İşlemlerde Saga Deseni (Orchestration vs. Choreography)
Senkron dağıtık mimarilerde kullanılan ACID garantileri, asenkron yapılarda yerini BASE (Basically Available, Soft state, Eventual consistency) prensiplerine bırakır. Birbiriyle ilişkili birden fazla sistemde (örneğin: E-Ticaret Platformu -> CRM -> WMS -> ERP) bir siparişin tamamlanması süreci bir “Saga” olarak kurgulanır.
- Choreography (Koreografi): Her servis bir event üretir ve diğer servisin event’ini dinleyerek kendi lokal transaction’ını yürütür. Merkezi bir denetleyici yoktur. Basit iş akışları için idealdir ancak servis sayısı arttığında akışın izlenebilirliği zorlaşır.
- Orchestration (Orkestrasyon): Camunda, Temporal veya Azure Durable Functions gibi bir orkestratör, süreci merkezi olarak yönetir. Servislerin asenkron yanıtlarına göre bir sonraki adımı tetikler. Adımlardan birinde hata oluştuğunda (örneğin ERP tarafında kredi limiti aşıldığında), orkestratör ters yönde çalışan telafi edici işlemleri (Compensating Transactions) tetikleyerek sistemleri tutarlı ilk hallerine geri döndürür.
Entegrasyon Modellerinin Teknik Karşılaştırması
Kurumsal entegrasyon kararlarında mimarların doğru teknoloji ve yaklaşımı seçebilmesi için senkron, kuyruk tabanlı ve olay akış (event-streaming) mimarilerinin karakteristik farklarını iyi analiz etmesi gerekir:
| Kriter | Senkron REST / SOAP API | Asenkron Mesajlaşma (RabbitMQ / Service Bus) | Olay Akışı (Apache Kafka / AWS Kinesis) |
|---|---|---|---|
| Bağımlılık (Coupling) | Yüksek (Temporal ve Spatial bağ) | Gevşek (Producer ve Consumer ayrımı var) | Tamamen Bağımsız (Event replay kabiliyeti) |
| Gecikme (Latency) | Anlık yanıt beklenir (Bloke edici) | Sub-second (Arka plan işleme) | Milisecond (Yüksek hacimli akış) |
| Geri Basınç (Backpressure) | Desteklenmez (Sistem çökmelerine açık) | Mükemmel (Kuyruk birikimi ile absorbe edilir) | Mükemmel (Log partitioning ile yatay ölçeklenir) |
| Veri Saklama & Yeniden Oynatma | Yok (İstek kaybolursa veri gider) | Tüketildikten sonra mesaj silinir | Konfigüre edilebilir (Retention period boyunca saklanır) |
| Kurumsal Kullanım Senaryosu | Hızlı sorgular (Stok adedi teyidi) | İş emri kuyrukları, Görev dağıtımı | Uçtan uca finansal ve operasyonel durum senkronizasyonu |
Asenkron Veri Senkronizasyonunun Kritik Mühendislik Zorlukları
Idempotency (Çift İşleme Koruması)
Asenkron ağlarda iletim garantileri genellikle “At-least-once” (En az bir kez) düzeyindedir. Network timeout’ları, consumer yeniden başlatmaları veya broker yeniden dengelenmesi (rebalance) durumlarında aynı event consumer sistemine birden fazla kez ulaşabilir. Eğer finansal bir ERP’ye aynı tahsilat kaydı iki kez işlenirse sistem tutarlılığı tamamen bozulur. Bu nedenle consumer servisler mutlak surette idempotent tasarlanmalıdır. Gelen mesajın benzersiz bir anahtarı (örneğin Idempotency-Key: EventID veya TransactionUUID), consumer tarafında hızlı bir önbellekte (Redis) veya veritabanı unique index kontrolünde sorgulanmalı; daha önce işlenmiş bir mesaj tespit edildiğinde işlem tekrarlanmadan başarı (ACK) dönülmelidir.
Mesaj Sıralaması (Strict Ordering)
İş süreçlerinde durum makineleri (State Machine) katı bir sıralamaya tabidir. Bir malzeme kartı önce oluşturulmalı (ItemCreated), ardından güncellenmeli (ItemUpdated) ve sonrasında onaylanmalıdır (ItemActivated). Asenkron mimarilerde bu mesajların sırasının bozulması mantıksal veri bozulmalarına neden olur. Apache Kafka gibi platformlarda bu sorun Partition Key stratejisiyle çözülür. İlgili varlığın tekil anahtarı (örneğin SKU veya CustomerID) partition key olarak atandığında, o varlığa ait tüm event’ler deterministik bir hash algoritması ile aynı log partition’ına yönlendirilir. Tüketici servis bu partition’ı sıralı okuduğu için durum sıralaması garanti altına alınır.
Zehirli Mesajlar ve Dead Letter Queue (DLQ)
Yapısal olarak bozuk veya iş mantığı kurallarını ihlal eden bir event (örneğin zorunlu bir para birimi alanının boş gelmesi), consumer servisin hata fırlatarak kuyruğu kilitlemesine neden olabilir. Bu durumu engellemek amacıyla Exponential Backoff (üstel geri çekilme) ve Jitter algoritmaları ile belirli sayıda yeniden deneme (retry) uygulanmalı; sorun çözülmüyorsa mesaj otomatik olarak bir Dead Letter Queue (DLQ) havuzuna taşınmalıdır. DLQ üzerindeki mesajlar, operasyonel ekiplerin kök neden analizi yapabilmesi ve düzeltme sonrası mesajı yeniden işleme sokabilmesi (re-drive) için merkezi izleme sistemlerine bağlanmalıdır.
Yönetişim, Veri Güvenliği ve Kurumsal Standartlar
Event-Driven ERP mimarilerinde sistemlerin bütünlüğü, güçlü bir şema yönetişimi (Schema Governance) ile korunur. Apache Avro veya Protocol Buffers (Protobuf) gibi binary serileştirme formatları, Confluent Schema Registry benzeri yapılar üzerinden denetlenmelidir. Şema evriminde (Schema Evolution) yalnızca “Geriye Dönük Uyumluluk” (Backward Compatibility) veya “Tam Uyumluluk” (Full Compatibility) kurallarına izin verilmeli; producer tarafında yapılan bir alan değişikliğinin downstream ERP süreçlerini kırması CI/CD pipeline aşamasında engellenmelidir.
Veri güvenliği açısından ise, kuyruktan geçen kurumsal verilerin (PII, finansal kayıtlar) Zero-Trust prensiplerine uygun şekilde korunması şarttır. Broker ile iletişim mTLS (Mutual TLS) ve SASL/SCRAM yetkilendirmesiyle şifrelenmeli; hassas yükler (payload) uygulama katmanında Envelope Encryption teknikleri kullanılarak asimetrik anahtarlarla kriptolanmalıdır. Dağıtık izlenebilirlik (Distributed Tracing) içinse OpenTelemetry standartları benimsenmeli, ERP’den çıkan ilk istekten son kuyruk tüketimine kadar aynı traceparent ve correlation_id taşınarak tüm yaşam döngüsü APM araçları (Dynatrace, Datadog) üzerinden uçtan uca gözlemlenebilmelidir.
Mühendislik & Mimari Notu: Bu teknik analiz ve kurumsal yol haritası; ölçeklenebilirlik, veri güvenliği ve yüksek mimari standartlar gözetilerek Nasuh AKAY (Data Architecture Solutions) tarafından hazırlanmıştır.
