Yazar: Bahadır Hakan Yüksel

• Merhaba! Ben Bahadır. Bu yazımda sizlere, baştan uca tasarlayıp geliştirdiğim OmniSync projesinin mimarisini, dağıtık sistemlerde veri kaybının nasıl önlendiği, güvenilirliğinin nasıl sağlandığını ve yapay zeka destekli modern bir kurumsal altyapının nasıl inşa edilebileceğini anlatacağım. Keyifli okumalar!

OmniSync Nedir?

OmniSync, modern mikroservis mimarilerindeki en büyük sorunlardan biri olan “İkili Yazma (Dual-Write)”
problemini çözmek amacıyla geliştirilmiş, Sıfır-Veri-Kaybı (Zero-Data-Loss) odaklı kurumsal bir denetim ve
işlem merkezidir.

OmniSync Ne İşe Yarar?

• İşlemsel yükler (OLTP), analitik (OLAP) ve yapay zeka aramalarını aynı anda, birbirlerini bloklamadanve veri kaybetmeden yönetmenizi sağlar.
• Finansal işlemleri şifreleyerek veritabanında değiştirilemez (Immutable) bir denetim mekanizması kurar.
• Çökmelere karşı sistemin kendini saniyeler içinde toparlamasını (Self-Healing) ve felaket anındakayıpsız geçmişe dönmeyi (PITR) sağlar.
• Kişisel verileri (KVKK) sızdırmadan vektörel ve semantik aramalar yapmanıza olanak tanır.

Kısacası; geleceğin büyük ölçekli ve veri odaklı sistemlerinin güvenle çalışması için tasarlanmış uçtan uca bir altyapı sunar.

 

1. Özet

Günümüzün büyük ölçekli ve veri odaklı tüm kurumsal yazılım sistemlerinde (e-ticaret, lojistik,
finans, sağlık vb.) veri bütünlüğünün sağlanması, yüksek erişilebilirlik (high availability) ve anlık
veri analitiği en kritik mühendislik problemlerinin başında gelmektedir. Monolitik mimarilerden
mikroservis mimarilerine geçiş, beraberinde veri tutarsızlığı (data inconsistency), ikili yazma (dual-
write) ve dağıtık mutabakat (distributed consensus) gibi çözülmesi zor zorluklar getirmiştir. Bu
makale, “Sıfır-Veri-Kaybı (Zero-Data-Loss)” hedefiyle yola çıkarak baştan uca tasarlanan
OmniSync olay güdümlü (event-driven) mimarisini incelemektedir. Sistem, Transactional Outbox
Pattern ve Change Data Capture (CDC) yöntemlerini harmanlayarak ikili yazma problemini ortadan
kaldırmış; Kafka tabanlı asenkron veri yolu ile ClickHouse (OLAP) ve Qdrant (Yapay Zeka /
Semantik Arama) katmanlarını eşzamanlı olarak besleyen çok modelli bir kalıcılık (Polyglot
Persistence) altyapısı kurmuştur. Ayrıca makale, projenin mimari kararlarını CAP Teoremi,
Raft/Paxos Mutabakat algoritmaları ve Zamanda Yolculuk (PITR) yedekleme stratejileri gibi teorik
altyapılarla harmanlayarak değerlendirmektedir.

2. Giriş ve Temel Problemler

Geleneksel web uygulamalarında, istemciden gelen bir istek doğrudan tek bir ilişkisel veritabanına
(RDBMS) yazılır ve süreç tamamlanır. Ancak sistem ölçeği büyüdüğünde ve verinin hem ana
veritabanına (PostgreSQL), hem analiz motoruna (ClickHouse), hem arama motoruna
(Elasticsearch / Qdrant), hem de önbelleğe (Redis) yazılması gerektiğinde büyük bir darboğaz
oluşur.
Eğer uygulama bu veritabanlarına sırayla yazmaya çalışırsa (Senkron Yazma):

1. İkili Yazma (Dual-Write) Problemi: Sistemin birinci veritabanına yazıp, ikinciye yazarken
   çökmesi durumunda veriler arası kalıcı bir tutarsızlık (Inconsistency) meydana gelir.
2. Gecikme (Latency): Tüm sistemlere verinin iletilmesini beklemek, son kullanıcıya dönen
   yanıt süresini (Response Time) dramatik ölçüde artırır.
3. Sıkı Bağ (Tight Coupling): Sistemlerden biri (örneğin analitik sunucusu) çökerse, ana
   uygulamanın da çökmesine veya hata fırlatmasına neden olur.
   Bu bağlamda OmniSync projesinin temel amacı; mikroservislerin birbirlerine sıkı sıkıya bağlı
   kalmadan (Decoupled), veriyi en yüksek hızla, %100 doğrulukla ve kayıpsız bir şekilde
   işleyebileceği bir altyapı (Event-Driven Architecture) inşa etmektir.

Bu bağlamda OmniSync projesinin temel amacı; mikroservislerin birbirlerine sıkı sıkıya bağlı
kalmadan (Decoupled), veriyi en yüksek hızla, %100 doğrulukla ve kayıpsız bir şekilde
işleyebileceği bir altyapı (Event-Driven Architecture) inşa etmektir.

 

3. Dağıtık Sistem Teorisi ve Mimari Kararlar

Projenin temelini oluşturan olay güdümlü mimarinin arkasında köklü bir dağıtık sistem teorisi
yatmaktadır. Tasarım aşamasında aşağıdaki teorik konseptler incelenmiş ve sistem mimarisi bu
prensipler üzerine inşa edilmiştir.

3.1. CAP Teoremi Uyum Stratejisi

Dağıtık sistemlerin temel kuralı olan CAP Teoremi (Consistency, Availability, Partition Tolerance),
bir sistemin ağ bölünmesi (Network Partition) anında ya Tutarlılık (Consistency) ya da
Erişilebilirlik (Availability) arasında bir seçim yapması gerektiğini söyler. OmniSync mimarisi,
finansal bir altyapı simülasyonu olduğu için CP (Consistency & Partition Tolerance) tabanlı bir
tasarıma yönelmiştir. İşlemlerin her zaman doğru ve tutarlı (Consistent) olması, sistemin zaman
zaman geç yanıt vermesine (Availability feragatı) tercih edilmiştir. Bu yüzden sistemin kalbinde
güçlü tutarlılık (Strong Consistency) sağlayan ACID uyumlu PostgreSQL kullanılmıştır.

3.2. Dağıtık Mutabakat (Consensus): Raft, Paxos ve Zookeeper

Sistemde asenkron mesajlaşmayı sağlayan Apache Kafka, arka planda broker’lar arası lider seçimi
ve veri senkronizasyonu için Zookeeper kullanmaktadır. Zookeeper, temellerini Paxos
algoritmasından alan ZAB (Zookeeper Atomic Broadcast) protokolü ile çalışır. Araştırmalarımızda,
düğümlerin (nodes) çöktüğü senaryolarda Split-Brain (bölünmüş beyin) sorununu önlemek için Raft
veya Paxos gibi Quorum (çoğunluk oyu) tabanlı mutabakat protokollerinin şart olduğu görülmüştür.

Görsel 1: Kafka ve Zookeeper Terminal Logları – Lider Seçimi ve Mutabakat

3.3 Dağıtık İşlemler (Distributed Transections): 2PC vs Saga

Farklı veritabanlarına aynı anda yazma gereksinimi için Two-Phase Commit (2PC) algoritması
incelenmiştir. Ancak 2PC’nin “hazırlık” (prepare) ve “onaylama” (commit) aşamalarındaki
bloklayıcı (blocking) doğası performansı öldürmektedir. Bu nedenle projemizde 2PC yerine, Event-
Sourcing ve Saga Pattern ile entegre çalışabilen Transactional Outbox Pattern tercih edilmiştir.

 

4. OmniSync Mimarisinin Pratik Uygulanması

Projede teorik araştırmalar somut bir yazılım mimarisine dönüştürülmüştür.

4.1. Veri Üretimi ve CDC (Change Data Capture)

Go (Gin) diliyle yazılan yüksek performanslı Core API, gelen finansal transfer işlemlerini doğrudan
transactions (İşlemler) tablosuna ve aynı Transaction (ACID) içinde outbox_events
(Giden Kutusu) tablosuna yazar. Sisteme entegre edilen Debezium, PostgreSQL’in Write-AheadLog (WAL) dosyalarını milisaniye seviyesinde okuyarak (CDC yaklaşımı) bu değişiklikleri yakalar.
Uygulama veritabanına yazdıktan hemen sonra çökse dahi, veritabanına işlenen log, Debezium
tarafından kesinlikle (At-Least-Once) Kafka’ya aktarılır. Bu, “Zero-Loss” hedefimizin bir numaralı
anahtarıdır.

Görsel 2: Go API İşlem Aksiyonları ve Outbox Logları – 1

Görsel 3: Go API İşlem Aksiyonları ve Outbox Logları – 2

4.2. Kriptografik Değiştirilemezlik (Immutability ve Merkle Tree)

Dağıtık defter teknolojilerinden (DLT/Blockchain) ilham alınarak, sisteme giren her finansal işlem
SHA-256 ile şifrelenir. İşlemin metadataları (Gönderen, Alıcı, Miktar) ve bir önceki işlemin Hash’i
harmanlanarak işlemin dijital mührü (Merkle Hash) oluşturulur. Bu yaklaşım, içeriden yapılabilecek
kötü niyetli veritabanı manipülasyonlarını (Data Tampering) engeller. Veritabanındaki bir rakam
değiştirilirse zincir kopar ve hile anında tespit edilir.

Görsel 4: PostgreSQL Merkle Hash Şifreleme Kanıtı

4.3. Yapay Zeka Entegrasyonu: Semantic Search ve Qdrant

Modern sistemlerde SQL sorguları sadece kesin eşleşmelerde çalışır. OmniSync mimarisine,
“anlamsal” (Semantic) sorgular yapabilmek için Python tabanlı bir AI Worker eklenmiştir.

• Kafka’daki olay akışını dinleyen Python Worker, verileri alır ve FastEmbed (BAAI/bge-
  small-en-v1.5) dil modeliyle 384 boyutlu vektörlere dönüştürür.
• Vektörler, vektör veritabanı olan Qdrant‘a kaydedilir.
• Sıfır Bilgi (Zero-Knowledge): Kullanıcı gizliliğini (KVKK/GDPR) korumak adına, Qdrant
  içerisine isim veya bakiye gibi Kişisel Veriler (PII) metin olarak kaydedilmez. Sadece
  vektörel matrisler ve işlemin asıl UUID’si saklanır.

Görsel 5: Qdrant Yapay Zeka Semantik Arama Sonuçları

4.4. Analitik Ölçeklenebilirlik: ClickHouse OLAP

PostgreSQL işlemsel veri yükünde (OLTP) kusursuzken, milyonlarca satırlık rapor çekimlerinde
(OLAP) sistemi kitleyebilir. Bunu engellemek için sisteme sütun odaklı (Columnar) veritabanı olan
ClickHouse dahil edilmiştir. ClickHouse içerisindeki Kafka Engine özelliği sayesinde, Kafka’dan
akan veriler harici bir ETL aracına ihtiyaç duymadan, saniyede yüzbinlerce satır hızla Materialized
View tablolarına işlenmektedir.

Görsel 6: ClickHouse Gerçek Zamanlı Analitik (Materialized View)

4.5. “Heavy” Broker’a Alternatif: Native PostgreSQL Pub/Sub

Kafka gibi devasa bağımlılıkların (Zookeeper, JVM vs.) küçük mikroservis projeleri için fazla
hantal (Overhead) olabileceği değerlendirmesi yapılarak, mimarisine alternatif bir “Hafif” olay
dağıtım sistemi tasarlanmıştır. PostgreSQL’in yerleşik LISTEN/NOTIFY (TCP Socket tabanlı
Pub/Sub) özelliği prototiplenmiş ve sistem içi anlık arayüz bildirimleri Kafka’ya uğramadan
milisaniyeler içinde Go API ve Next.js arayüzüne başarıyla iletilmiştir.

Görsel 7: Native PostgreSQL Pub/Sub İletişimi

 

5. Felaket Kurtarma, Yedekleme ve Kaos Mühendisliği

Mimarinin güvenilirliğini kanıtlamak için projede Kaos Mühendisliği (Chaos Engineering)
uygulanmış; çalışan veritabanından kasten tablolar silinerek felaket (Disaster) anı simüle edilmiştir.
Arayüzün bu kesintileri anında yakalaması için bir Gözlemlenebilirlik (Observability) modülü
kodlanmıştır.

Görsel 8: Next.js Yönetim Paneli – Kaos Testi Çökme Anı

Hedeflenen RPO (Kurtarma Noktası Hedefi) sıfır (0) ve RTO (Kurtarma Süresi Hedefi) < 5 Dakika
kriterlerini sağlamak için yazılan özel kabuk betiği (backup_manager.sh) şu işlemleri
gerçekleştirmektedir:

1. Mantıksal Yedekleme (Logical): Sistemi durdurmadan (Zero-Downtime) yapısal SQL
   aktarımları (pg_dump).
2. Fiziksel Yedekleme (Physical Snapshot): Veritabanının dosya sistemi düzeyindeki anlık
   kopyaları (pg_basebackup).
3. Zamanda Yolculuk (Point-in-Time Recovery – PITR): WAL arşivleri kullanılarak,
   veritabanının örneğin saat 15:32:14’teki haline (salise şaşmadan) geri döndürülmesi
   başarıyla test edilmiştir.

Görsel 9: Sıfır Kesinti (Zero-Downtime) Yedekleme ve PITR

 

6. Sistem Performans Metrikleri ve Mimari Tavizler (Trade-offs)

Her sistem tasarımında mükemmellik arayışı belirli teknik tavizler (trade-offs) vermeyi gerektirir.
OmniSync mimarisinde Sıfır-Veri-Kaybı hedefine ulaşabilmek için bazı maliyetlere katlanılmıştır.

6.1. Performans Testi Sonuçları (Benchmark)

Lokal simülasyon ortamında yapılan ilk yük testlerinde elde edilen sonuçlar şöyledir:

• API İşlem Kapasitesi: Go (Gin) altyapısı sayesinde Core API, 50 eşzamanlı bağlantı
  (concurrency) ile yapılan canlı yük testlerinde (Apache hey benchmark aracı kullanılarak)
  saniyede ortalama 4.535 TPS (Transaction Per Second) gibi muazzam bir işlem yükünü
  hatasız karşılamıştır. İsteklerin %50’si (p50 latency) 9.5 ms hızında tamamlanırken, %99’luk
  yoğunluk dilimi (p99) veritabanı çift yazma (Outbox) işlemlerine rağmen 28.8 ms
  seviyesinde kalarak gerçek zamanlı işlem limitlerini zorlamıştır.

Görsel 10: Apache Hey ile Yük Testi

• CDC ve Kafka İletim Gecikmesi (Lag): İşlemin veritabanına yazılması ile Debezium
  tarafından yakalanıp Kafka’ya iletilmesi arasındaki süre ortalama < 15 ms (milisaniye)
  seviyesindedir.
• Yapay Zeka (Qdrant) Arama Hızı: 1.000.000 (Bir milyon) vektörel kayıt üzerinden
  yapılan Cosine Similarity (Kosinüs Benzerliği) aramaları ortalama 35-45 ms içinde sonuç
  vermiştir.
• Analitik Gecikme: ClickHouse’un Materialized View’lara veriyi işlemesi < 50 ms
  sürmektedir. Yani Dashboard verileri saniyenin yirmide biri kadar bir gecikmeyle (Real-
  time) ekrana yansımaktadır.

6.2. Mimari Tavizler (Dezavantajlar ve Maliyet)

• Depolama (Storage) Maliyeti: Veriler ana veritabanı (PostgreSQL), analitik motoru
  (ClickHouse) ve vektör veritabanı (Qdrant) olmak üzere üç farklı noktaya yazılmaktadır. Bu
  durum depolama maliyetlerini (Storage Cost) standart bir monolitik sisteme göre 3 katına
  çıkarmaktadır.
• Bakım Karmaşıklığı (Overhead): Zookeeper ve Kafka gibi bağımlılıkların yönetimi, JVM
  bellek (Heap) tüketimi ve konfigürasyon eforu, küçük projeler için fazla ağır bir altyapı
  oluşturmaktadır.

7. Sistem Güvenliği ve Gelecek Çalışmalar (Future Work)

7.1. Güvenlik Katmanı: Derinlemesine Savunma (Defense in Depth)

Kurumsal bir mimaride sadece API şifreleri ile savunma yapmak kesinlikle yeterli değildir. OmniSync,
“Derinlemesine Savunma” (Defense in Depth) prensibini temel alır. Bu vizyon doğrultusunda, sistemin
halihazırda başarıyla uyguladığı ve canlı (Production) ortam için hedeflediği katmanlı güvenlik yaklaşımı
şöyledir:

1. Kimlik Doğrulama ve Yetkilendirme (AuthN & AuthZ): Dış dünyaya açılan Go API uç
   noktaları JWT ile korunurken, sistem içinde Rol Tabanlı Erişim Kontrolü (RBAC) uygulanır.
   Her kullanıcının sadece kendi yetki alanındaki işlemleri yapması sağlanır.
2. Ağ İzolasyonu ve Şifreleme (Network & mTLS): PostgreSQL, Kafka, ClickHouse ve
   Qdrant dış internete kapalı, izole edilmiş sanal ağlarda (VPC / Docker Internal Network)çalışır. İlerleyen süreçte mikroservisler arası tüm iç trafik mTLS (Mutual TLS) ile
   şifrelenecektir.
3. API Gateway ve Hız Sınırlandırma (Rate Limiting): Go API’nin önünde Kong veya
   Nginx gibi bir API Gateway konumlandırılarak, dışarıdan gelebilecek DDoS saldırılarına ve
   Brute-Force denemelerine karşı Rate Limiting uygulanması şarttır.
4. Kişisel Veri (PII) Korunması: Qdrant veritabanında uygulandığı gibi (Zero-Knowledge
   tasarımı), kullanıcıların isim veya bakiye gibi hassas verileri vektör matrislerinden tamamen
   arındırılarak KVKK/GDPR uyumluluğu sağlanmıştır.

7.2. Gelecek Vizyonu

Yazılım süreçleri sürekli bir evrim (evolution) halindedir. Projenin bir sonraki fazı için planlanan
iyileştirmeler şunlardır:

• Zookeeper Bağımlılığından Kurtuluş: Kafka’nın Zookeeper yerine kendi iç Raft
  mutabakat mekanizmasını (KRaft) kullandığı yeni sürümüne geçiş yapılacaktır. Bu,
  mimariyi hafifletecektir.
• Kubernetes (K8s) Otomasyonu: Mevcut Docker Compose altyapısı Kubernetes’e
  taşınacak; trafik aniden arttığında Go API, Python AI Worker ve Kafka Broker’ları otomatik
  olarak ölçeklenecektir (Auto-scaling / HPA).
• Redis Caching: Aynı kelimelerle sürekli yapılan yapay zeka aramalarını (Semantic Search)
  hızlandırmak ve Qdrant’ın yükünü hafifletmek için araya Redis Cache katmanı eklenecektir.

8. Proje Değerlendirmesi ve Sonuç

Modern yazılım mühendisliğinde farklı iş yükleri için farklı veritabanlarının kullanılması (Polyglot
Persistence) artık bir yenilik değil, mutlak bir endüstri standardı haline gelmiştir. İşlemsel yükler
(OLTP) için RDBMS, analitik (OLAP) için sütun odaklı sistemler ve Yapay Zeka için Vektör
veritabanlarının bir arada kullanılması kaçınılmazdır. Ancak asıl mühendislik zorluğu, bu
sistemlerin kendi aralarında veri kaybetmeden ve tutarsızlık oluşturmadan nasıl asenkron iletişim
kuracağıdır.
Bu projede tasarlanan OmniSync mimarisi; Debezium ve Kafka tabanlı Outbox Pattern kullanarak
bu iletişim problemini başarıyla çözmüş ve yerel test ortamında 4.535 TPS gibi yüksek bir işlem
kapasitesine ulaşmıştır. Merkle Tree tabanlı veri güvenliği, test edilmiş yedekleme senaryoları
(PITR) ve AI destekli arama motoru ile entegre çalışan bu sistem, ölçeklenebilir modern kurumsal
altyapılar için başarılı bir Kavram Kanıtı (Proof of Concept – PoC) ve yenilikçi bir prototip
niteliği taşımaktadır.