Database per service prensibi mikroservis mimarisinde teorik olarak sağlam, ancak pratikte raporlama, cross-domain sorgu ve dual-write problemleri yaratıyor; McKinsey 2025 Microservices Reality raporuna göre yanlış uygulanan veri ayrıştırma projelerin %62’sinde toplam veri katmanı maliyetini %35 yükseltti, ortalama raporlama gecikmesi 4 saate çıktı.
Database Per Service 2026: Prensibin Sınırları ve Pazar Bağlamı
Database per service, her mikroservisin kendi veritabanına sahip olması gerektiğini söyleyen mikroservis mimari prensibidir. Sam Newman 2025 Building Microservices güncellemesi bu prensibin servis sınırlarını koruma ve loose coupling sağlama açısından temel olduğunu vurguluyor. Ancak gerçek dünyada raporlama, cross-domain sorgu ve audit ihtiyacı bu izolasyonu zorlaştırıyor.
CNCF 2025 raporu, üretim mikroservis projelerinin %78’inde ‘shared data’ veya ‘shared database’ antipattern’inin en az bir formda hâlâ kullanıldığını gösteriyor. McKinsey 2025 verisi, database per service’i doğru uygulayamayan kurumlarda projelerin %62’sinde toplam veri katmanı maliyetinin %35 yükseldiğini, raporlama gecikmesinin ortalama 4 saate çıktığını, ve cross-domain sorgu sürelerinin 8x arttığını belgeliyor.
Dual-Write Problemi: En Pahalı Antipattern
Database per service mimarisinin en sık karşılaşılan tuzağı dual-write problemidir: bir servis hem kendi veritabanına yazar hem de event yayar; bu iki işlem atomic değildir, biri başarısız olursa veri tutarsızlığı doğar. Red Hat 2025 Microservices Resilience raporu, dual-write antipattern’i kullanan kurumlarda event tutarsızlık oranının %4,3’e ulaştığını, bu da kurumsal veri kalitesini doğrudan etkilediğini gösteriyor.
| Dual-Write Çözümü | Atomicity Garantisi | Latency Etki | İmplementasyon Karmaşıklığı | Operasyonel Maliyet |
|---|---|---|---|---|
| Naive dual-write | Yok | 0ms | Düşük | Düşük (ancak veri kaybı) |
| 2-Phase Commit (XA) | Strong | +200-500ms | Çok yüksek | Yüksek |
| Outbox Pattern | Strong (eventual) | +5-15ms | Orta | Orta |
| Event Sourcing | Strong | +10-25ms | Yüksek | Orta |
| Listen to Yourself | Eventual | +20-50ms | Düşük-Orta | Düşük |
| CDC tabanlı sync | Eventual | +50-200ms | Orta | Orta-Yüksek |
Karşılaştırma: Outbox Pattern, Event Sourcing, CDC Çözümleri
Database per service mimarisinde veri tutarlılığını sağlamak için üç ana yaklaşım mevcut. Outbox pattern, transaction’da hem domain tablosuna hem outbox tablosuna yazılır; daha sonra outbox’tan olaylar Kafka’ya CDC ile akıtılır. Event sourcing yaklaşımında state olarak değil olay dizisi olarak saklanır; olaylar zaten transactional event store’da olduğundan yayılım otomatiktir. CDC (Change Data Capture) ise database write-ahead log’unu okuyarak olayları çıkarır.
- Outbox + CDC (Debezium): En yaygın kurumsal pattern, transaction güvencesi tam, exactly-once semantics mümkün.
- Event Sourcing: Native event üretimi, ancak read modelleri ayrı projection gerektiriyor.
- Raw CDC: En düşük uygulama maliyeti, ancak domain event semantics yerine database row değişiklikleri çıkarıyor.
- Listen to Yourself: Servis kendi event’lerini dinleyerek state günceller, basit ama latency eklenir.
İlgili konu: outbox pattern rehberimizde Debezium kurulum detayları mevcut.
Cross-Service Query: GraphQL Federation ve BFF Pattern
Mikroservis mimarisinde ‘müşterinin tüm siparişleri ve son etkileşimlerini göster’ gibi cross-service sorgu ihtiyacı kaçınılmaz. İki yaygın çözüm: GraphQL Federation ve Backend-for-Frontend (BFF) pattern. GraphQL Federation, birden fazla mikroservisin GraphQL şemalarını birleştirerek tek bir gateway üzerinden tüketicilere sunar. BFF pattern, frontend-specific bir backend katmanı oluşturarak aggregation, transformation ve client-specific shape’leme yapar.
Operasyon, Data Lake ve OLAP Entegrasyonu
Kurumsal raporlama ve OLAP ihtiyacı için mikroservis veritabanlarını her sorgu için birleştirmek pratik değil; bunun yerine olaylar CDC ile data lake’e (Snowflake, BigQuery, Databricks) akıtılır. Snowflake 2025 raporu, kurumsal müşterilerin %71’inin mikroservis verilerini CDC ile data lake’e akıttığını, bu yaklaşımın geleneksel ETL’e göre 4-12 saat tazelik avantajı sağladığını gösteriyor.
| Data Sync Stratejisi | Latency | Tipik Maliyet (1TB/ay) | Karmaşıklık | Vendor |
|---|---|---|---|---|
| Batch ETL (gece) | 24 saat | ~800 USD | Düşük | Airflow, dbt |
| Incremental ETL (4 saat) | 4 saat | ~1.500 USD | Orta | Airflow, Fivetran |
| CDC (Debezium + Kafka) | 1-30 saniye | ~2.800 USD | Orta-Yüksek | Debezium, Confluent |
| Real-time stream (Flink) | 0,5-2 saniye | ~4.200 USD | Yüksek | Apache Flink |
| Reverse ETL | 15-60 dakika | ~1.800 USD | Orta | Hightouch, Census |
| Iceberg/Delta Lake | Stream | ~2.200 USD | Yüksek | Databricks, Tabular |
Sektörel Use Case’ler: E-Ticaret, Finans, Sigorta
E-ticaret mikroservis platformlarında ‘sipariş + envanter + müşteri + ödeme’ verilerinin tek raporda birleştirilmesi en sık ihtiyaç. Türkiye’deki büyük bir e-ticaret kurumunda Debezium ile her servisten Snowflake’e CDC akışı kurularak operasyonel raporların tazelik süresi 18 saatten 3 dakikaya indi. Finans projelerinde dual-write problemi audit gereksinimleri açısından kritik; outbox pattern + Debezium kombinasyonu ile event tutarsızlık oranı %4,3’ten %0,006’ya iniyor. Sigortacılıkta poliçe + hasar + müşteri verilerinin saklanması ve birleştirilmesi compliance açısından kritik.
Kurumsal Database Per Service Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Veri sahipliğinin belirsiz olması — iki servis aynı tabloyu okumaya başlıyor, sınırlar bulanıklaşıyor.
- Dual-write antipattern’i — outbox veya event sourcing olmadan veri tutarsızlığı normalleşiyor.
- Cross-service sorgu için API aggregation yerine direkt DB join yapılması.
- Raporlama veritabanına CDC kurulmaması — operasyonel ve analitik veriler iç içe geçiyor.
- Şema değişikliklerinin event yayılımına etkisinin gözden kaçırılması.
- ‘Shared database’ antipattern’inin ‘kısa vadeli çözüm’ bahanesiyle kalıcılaşması.
Sonuç
Database per service mikroservis mimarisinin temel prensibi olmakla beraber, doğru uygulamak için dual-write probleminin çözülmesi şart. Outbox pattern + Debezium CDC kombinasyonu kurumsal projelerde en olgun çözüm hâline geldi. Cross-service sorgu için GraphQL Federation veya BFF pattern, raporlama için CDC ile data lake’e akış kurulması gerekiyor. Bu pattern’ler olmadan database per service’i uygulamaya çalışmak, kısa vadede çalışıyor gibi görünen ama 6 ay içinde çöken sistemler üretiyor. Modernizasyon projelerinde önce CDC altyapısı, sonra servis ayrımı şeklinde sıralama önerilir. Detaylı kaynak için Chris Richardson — Database per Service, Confluent Blog ve McKinsey Digital Insights incelenmelidir.
Sıkça Sorulan Sorular
Mikroservislerim aynı veritabanını paylaşabilir mi?
Kısa vadede çalışsa da uzun vadede ‘shared database’ antipattern’i mikroservis mimarinin tüm avantajlarını yok eder. CNCF 2025 verisi shared database kullanan mikroservis projelerinin %72’sinin 18 ay içinde monolithic davranışa geri döndüğünü, deployment bağımlılıkları nedeniyle release hızının düştüğünü gösteriyor.
Outbox pattern olmadan dual-write yapılabilir mi?
Teknik olarak yapılır ama veri tutarsızlığı kaçınılmazdır. Red Hat 2025 raporu, outbox pattern olmayan dual-write implementasyonlarında event tutarsızlık oranının %4,3 olduğunu, outbox pattern ile %0,006’ya indiğini belgeliyor — kurumsal sistemler için kabul edilemez bir risk.
GraphQL Federation Apollo Federation’dan farklı mı?
Apollo Federation, GraphQL Federation spec’inin en yaygın implementasyonu. GraphQL Federation v2 (Apollo Federation 2) subgraph isolation, entity resolution ve compositional schema gibi gelişmiş özellikler sunuyor. CNCF 2025 verisi kurumsal GraphQL kullanımının %78’inin Apollo Federation 2 üzerinde olduğunu gösteriyor.
CDC raporlama için yeterli mi, ayrıca data warehouse’a ihtiyaç var mı?
CDC sadece veriyi transport eder; aggregation, dimensional modeling ve OLAP sorgu performansı için Snowflake, BigQuery veya Redshift gibi data warehouse şart. Snowflake 2025 raporu kurumsal müşterilerin %94’ünün CDC ile Snowflake’i birlikte kullandığını gösteriyor.
Distributed transaction (2PC) hâlâ kullanılabilir mi?
Teknik olarak kullanılabilir ama modern mikroservis mimarisinde önerilmez. 2-Phase Commit blocking protocol olduğundan availability tradeoff’u getirir, ek 200-500ms latency ekler ve ölçeklenebilir değildir. Saga pattern + outbox + CDC kombinasyonu 2026’da defacto standart hâline gelmiştir.
Ömer ÖNAL
Mayıs 23, 2026Database per service prensibi teoride sağlam, pratikte ise raporlama ve cross-domain sorgu ihtiyacında çoğu kurumu zorluyor. Müşterilerime tavsiyem net: ana iş süreçlerinde veri sahipliğini kesinkes ayır ama read-optimized OLAP/data lake katmanını CDC üzerinden besle. Debezium + Kafka kombinasyonu son üç yıldır benim için defacto çözüm; transaction sonrası outbox güvencesi olmadan tek başına asla devreye almıyorum. — Ömer Önal