1. GİRİŞ: MONOLİTİK VERİTABANINDAN ÖZGÜR SERVİSLERE

Yazılım dünyasında mikroservis mimarisine geçiş, ekiplerin daha hızlı ve bağımsız çalışmasını sağladı. Ancak bu dönüşümün en sancılı ve en kritik noktası her zaman "veri" olmuştur. Geleneksel monolitik yapılarda tüm servislerin ortak bir devasa veritabanına (Shared Database) bağlandığı model, mikroservislerin getirdiği "bağımsız ölçeklenebilirlik" ve "hızlı dağıtım" vaatlerini dinamitler. Data Microservices, verinin de servisler gibi parçalandığı, her servisin kendi verisinin mutlak sahibi olduğu bir mimari disiplindir.

2026 yılına geldiğimizde, veri mikroservisleri sadece bir "backend" tercihi değil, Cloud-native sistemlerin ve yapay zeka odaklı uygulamaların temel taşıdır. Verinin tek bir noktada toplanması yerine, işlevsel sınırlara (Bounded Context) göre dağıtılması, sistemlerin hem daha dirençli hem de daha esnek olmasını sağlar. Ancak bu özgürlük, beraberinde "veri tutarlılığı" (Data Consistency) ve "dağıtık işlemler" (Distributed Transactions) gibi karmaşık mühendislik problemlerini de getirir.

Bu Teknoloji Neden Bugün Konuşuluyor?

Günümüz uygulamaları artık saniyede milyonlarca isteği işlemek ve petabaytlarca veriyi yönetmek zorunda. Merkezi bir veritabanı, ne kadar güçlü donanımlara sahip olursa olsun, bir noktadan sonra fiziksel limitlere takılır. Data Microservices, bu limitleri "yatayda genişleyerek" (Horizontal Scaling) ve veriyi iş birimlerine dağıtarak aşar. Ayrıca, Poliglot Kalıcılık (Polyglot Persistence) sayesinde her servis için en uygun veritabanı teknolojisinin seçilmesine olanak tanır.

Kimler İçin Önemli?

Bu teknik rehber; Sistem Mimarları, Backend Geliştiriciler, Veri Mühendisleri ve DevOps Uzmanları için hazırlanmıştır. Monolitik bir veritabanından mikroservis tabanlı bir veri yapısına geçiş yapmayı planlayan veya mevcut dağıtık sistemindeki tutarlılık sorunlarını çözmek isteyen her mühendis için bir yol haritası niteliğindedir.

Hangi Problemleri Çözüyor?

• Tek Nokta Hatası (Single Point of Failure): Merkezi veritabanının durması tüm sistemi durdururdu; burada ise sadece ilgili servis etkilenir.
• Ölçekleme Darboğazları: Yazma yükü yüksek bir servisin veritabanı, okuma yükü yüksek bir servisten bağımsız olarak ölçeklenebilir.
• Bağımlılık (Coupling): Bir servisin şemadaki bir kolonu değiştirmesi, diğer servislerin kodunu bozmaz.
• Teknoloji Kısıtı: Tüm servisleri aynı SQL motoruna mahkum etmek yerine, ihtiyaca göre NoSQL, Graph veya Time-series veritabanları kullanılabilir.

2. KAVRAMSAL TEMELLER: VERİ MASKELEME DİSİPLİNLERİ

Data Microservices mimarisini başarılı kılan şey kütüphaneler değil, uygulanan desenler ve kavramsal doğruluktur.

2.1 Bounded Context (Sınırlı Bağlam)

Domain-Driven Design (DDD) disiplininin kalbi olan Bounded Context, bir veri mikroservisinin sınırlarını belirler. Örneğin; "Ürün" kavramı, "Stok Servisi" için fiziksel boyut ve sayı demekken, "Pazarlama Servisi" için açıklama ve görseller demektir. Data Microservices'te bu iki bağlam birbirinden izole edilir ve kendi veritabanlarına sahip olur.

2.2 Database per Service (Servis Başına Veritabanı)

Her mikroservisin kendine ait özel bir veritabanı alanına (schema, database instance veya cluster) sahip olmasıdır. Diğer servisler bu veritabanına doğrudan SQL sorgusu atamaz; veriye sadece servis API'ları üzerinden erişilir. Bu, tam kapsülleme (Encapsulation) sağlar.

2.3 Polyglot Persistence (Poliglot Kalıcılık)

Farklı veri türleri için farklı saklama teknolojilerinin kullanılmasıdır. Sipariş yönetimi için PostgreSQL (İlişkisel/ACID), kullanıcı oturumları için Redis (Bellek içi/Hız), sosyal ağ ilişkileri için Neo4j (Graph) kullanılması Data Microservices mimarisinin doğal bir sonucudur.

3. NASIL ÇALIŞIR? TEKNİK MİMARİ VE VERİ AKIŞI

Veri parçalandığında en büyük sorun "tutarlılığı nasıl sağlarız?" olur. Modern mimari bunu asenkron iletişim ve özel tasarım desenleriyle çözer.

3.1 Dağıtık İşlemler ve Saga Deseni (Saga Pattern)

Birden fazla servisi kapsayan bir işlem (Örn: Sipariş oluştur -> Ödeme al -> Stok düş) artık tek bir veritabanı transaksiyonuyla (BEGIN/COMMIT) yapılamaz. Saga Deseni, bu büyük işlemi küçük yerel işlemlere böler. - Choreography: Servisler olay (event) yayınlayarak birbiriyle haberleşir. "Sipariş oluşturuldu" eventi stok servisini tetikler. - Orchestration: Merkezi bir servis (Orchestrator) süreci yönetir ve sırayla her servise komut gönderir. Telafi İşlemi (Compensating Transaction): Eğer ödeme başarısız olursa, Saga sistemi daha önce düşülen stoğu geri yüklemek için bir "iptal" işlemi tetikler.

3.2 CQRS: Komut ve Sorgu Ayrımı

**Command Query Responsibility Segregation (CQRS)**, veriyi yazma ve okuma işlemlerini farklı modellerde ve hatta farklı veritabanlarında tutma tekniğidir. - Command: Yazma işlemleri (Create/Update/Delete) için optimize edilmiş model. - Query: Okuma işlemleri için optimize edilmiş, denormalize edilmiş (JOIN gerektirmeyen) model. Bu iki model arası senkronizasyon genellikle bir "Event Bus" (Kafka, RabbitMQ) üzerinden yapılır.

3.3 Event Sourcing: Verinin Tarihçesi

Verinin sadece "son halini" tutmak yerine (Örn: bakiye=100), bakiyeyi oluşturan tüm "olayları" (Örn: +50, -20, +70) saklama yöntemidir. Bu sayede sistemin herhangi bir andaki durumuna (Time Travel) dönülebilir ve veri değişim denetimi (Audit) mükemmel şekilde yapılır.

4. GERÇEK DÜNYA KULLANIMLARI: TEKNOLOJİ DEVLERİNİN VERİ MİMARİSİ

İnternet ölçeğinde çalışan şirketler, Data Microservices mimarisini zorunluluktan keşfetmiştir.

4.1 Netflix: binlerce Servis ve Eventual Consistency

Netflix, monolitik yapısını binlerce mikroservise bölerken "Database per Service" kuralını katı bir şekilde uyguladı. On binlerce mikroservis arasında veri bütünlüğü asenkron olaylarla sağlanır. Netflix için verinin "anlık" değil "nihai tutarlılığı" (Eventual Consistency) kritiktir. Bir izleme listesine eklediğiniz filmin saniyeler sonra diğer cihazınızda görünmemesi (geçici bir durum), sistemin tamamen çökmesinden daha iyidir.

4.2 Uber: Şema Değişim ve Mikroservis Yönetimi

Uber, veritabanı yönetimini servis sahiplerine bırakırken, veritabanı kaynaklarını (DBaaS) ortak bir platform üzerinden sunar. Uber'de her servis kendi SQL veya NoSQL şemasını yönetir. Uber'in en büyük başarısı, mikroservisler arası veri iletişimini standardize ederek (gRPC/Protobuf) şema değişimlerinin sistem genelinde yaratacağı riskleri minimize etmesidir.

4.3 Stripe: Finansal Tutarlılıkta Mikromodeller

Stripe, ödeme süreçlerini mikroservislere bölerken "Saga" ve "Idempotency" (Aynı işlemin tekrarında hataya düşmeme) prensiplerini merkeze alır. Stripe için veri mikroservisleri, yüksek kullanılabilirlik ve finansal hatasızlık (ACID kurallarını mikro seviyede işletmek) arasında bir dengedir. Stripe, iç sistemlerinde MongoDB tabanlı kendi özelleştirilmiş veritabanı cluster'larını kullanır.

4.4 Amazon: "Two-Pizza Teams" ve Veri Bağımsızlığı

Amazon'un meşhur kuralı: Bir ekip, iki pizza ile doyabilecek kadar küçük olmalı ve kendi servisinin veritabanına kadar her şeyinden sorumlu olmalıdır. Amazon.com'un ana sayfasındaki her bir widget (öneriler, sepet, fiyat), farklı bir veri mikroservisinden beslenir.

5. AVANTAJLAR VE SINIRLAMALAR: MÜHENDİSLİK ANALİZİ

Her mimari gibi Data Microservices de bir takastır (trade-off).

Avantajlar

• Bağımsız Dağıtım (Deployability): Bir servisin veritabanını güncellemek tüm sistemi ayağa kaldırmayı gerektirmez.
• Hata İzolasyonu (Blast Radius): Bir veritabanı bozulursa, sistemin sadece o parçası devre dışı kalır.
• Ölçeklenebilirlik: Sadece çok yük alan mikro-veritabanlarını dikeyde veya yatayda büyütebilirsiniz.
• Geliştirici Hızı: Ekiplerin diğer ekiplerin veritabanı şemalarını bilmesine gerek kalmaz, sadece API kontratlarına odaklanırlar.

Sınırlamalar ve Dezavantajlar

• Veri Tutarlılığı (Consistency): Gerçek zamanlı ACID işlemleri dağıtık yapıda imkansızdır; "Eventual Consistency" kabul edilmelidir.
• Operasyonel Karmaşıklık: 1 veritabanı yönetmek yerine 50 tane yönetmek (monitoring, backup, patching) ek bir yük getirir.
• Dağıtık Sorgu Zorluğu (Distributed Queries): JOIN işlemleri artık veritabanı seviyesinde yapılamaz; kod seviyesinde veya API Gateway üzerinden "composition" yapılması gerekir.
• Transaksiyon Yönetimi: Hatalı bir durumda veriyi eski haline getirmek (Compensating transactions) kod karmaşıklığını artırır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA: MESH VS MICROSERVICES

Data Microservices'i diğer yaklaşımlarla karşılaştıralım:

7. EN İYİ PRATİKLER: PRODUCTION SEVİYESİNDE UYGULAMA

Veri mikroservislerini kurgularken bu prensiplere sadık kalınması başarının anahtarıdır.

Production Kullanımı ve Domain Tasarımı

• Önce Domain'i Parçalayın: Teknik değil, iş birimlerine göre (Domain-Driven Design) ayrışma yapın.
• API-First Yaklaşımı: Veritabanı modelini değil, servis API kontratını önceliklendirin.
• Idempotency (Eşgüçlü İşlemler): Bir mesajın (event) ağ hatası nedeniyle iki kez gelmesi durumunda sistemin veriyi bozmadığından emin olun.

Performans ve Güvenlik

• Caching Katmanı: Dağıtık sistemlerin yarattığı gecikmeyi (latency) Redis gibi araçlarla minimize edin.
• API Gateways & Composition: Kullanıcıya veri sunarken birden fazla servisin verisini arka planda birleştirip (API Composition) tek seferde sunun.
• Centralized Logging: Dağıtık traceler (Zipkin, Jaeger) kullanarak bir işlemin hangi veri servisinde tıkanıklık yarattığını görün.

Yönetişim ve Dayanıklılık

• Circuit Breaker: Bir veri servisi yavaşsa veya cevap vermiyorsa, isteği anında keserek tüm sistemin kaynağını tüketmesini engelleyin.
• Fallback Mekanizmaları: Kritik bir servis durduğunda "cache'lenmiş veri" veya "varsayılan değer" ile hizmet vermeye devam edin.

8. SIK YAPILAN HATALAR: GELİŞTİRİCİLERİ BEKLEYEN TUZAKLAR

• Dağıtık Monolit Yaratmak: Servisleri böldüğü halde her servisi hala ortak bir veritabanına bağlamak. Bu, monolitizmin tüm dezavantajlarını taşır ama mikroservis karmaşıklığını da ekler.
• Aşırı Bölünme (Nano-services): Veriyi o kadar küçük parçalara ayırmak ki her basit işlem 10 servis gezmek zorunda kalsın. Bu, ağ trafiğini boğar.
• Audit Loglarını Unutmak: Dağıtık yapıda "bu veriyi kim değiştirdi?" sorusunun cevabı zordur. Event sourcing veya CDC (Change Data Capture) kullanılmalıdır.
• Senkron İletişim Israrı: Tüm servisleri birbirine REST API ile sıkı sıkıya bağlamak. Bir servis çökerse zincirleme olarak hepsi çöker (Cascading failure).
• Yanlış DB Seçimi: Sadece "popüler" olduğu için ihtiyacı olmayan bir yere Graph veritabanı sokmak.

9. GELECEK TRENDLER: VERİ MİKROSERVİSLERİ VE AI

Mimari yaklaşımlar teknolojik sıçramalarla birleşiyor.

9.1 Serverless Data Microservices

2026 sonrası, mikroservislerin sadece "logic" kısmı değil, veritabanı katmanı da serverless olacak (Örn: Aurora Serverless, MongoDB Atlas Serverless). Bu, kullanılmayan servisler için sıfır maliyet ve sonsuz ölçeklenebilirlik demektir.

9.2 AI Destekli Veri Senkronizasyonu

Yapay zeka, mikroservisler arasındaki veri akış modellerini analiz ederek, hangi verilerin hangi servislere "pre-cache" edilmesi gerektiğini veya hangi servislerin birleşmesi gerektiğini (Domain Merge) önerebilecek.

9.3 Data Mesh Entegrasyonu

Data Microservices operasyonel (transactional) tarafa odaklanırken, Data Mesh analitik tarafa odaklanır. Gelecekte bu iki mimari, "Data Product" kavramı altında tek bir çatı altında birleşecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Veriler parça parçayken raporlama (Reporting) nasıl yapılır?

   Fiziksel mikro-veritabanlarından rapor çekilmez. Tüm veriler bir "Event Bus" üzerinden merkezi bir Data Warehouse veya Data Lake'e (Analytical data) akar ve raporlama buradan yapılır.

2. İki servis aynı tabloya ihtiyaç duyarsa ne yapmalıyız?

   Eğer her ikisi de veriyi değiştirecekse bu bir domain tasarım hatasıdır. Eğer biri yazıyor diğeri sadece okuyorsa, yazan servis okuyan servise olay (event) göndermeli ve okuyan servis verinin kendi kopyasını (redundancy) tutmalıdır.

3. Mikroservislere geçmek veritabanı maliyetini artırır mı?

   Evet, her servis için ayrı bir instance yönetmek başlangıç maliyetini artırabilir. Ancak bulut tabanlı ve konteynerize edilmiş çözümler bu maliyeti yönetilebilir kılar.

4. Transaction yönetimi için neden 2PC (Two-Phase Commit) kullanılmaz?

   2PC ağ gecikmelerine karşı çok hassastır ve tüm sistemin kilitlenmesine neden olabilir (Locking). Modern mimariler bunun yerine "Eventual Consistency" ve Saga tercih eder.

5. Test süreçleri nasıl yönetilir?

   Her servis kendi veritabanını bir Docker container olarak ayağa kaldırır ve bağımsız testlerini yapar. Entegrasyon testleri ise "Service Mocking" ile gerçekleştirilir.

6. Veri mikroservisi ölçeklenirken disk alanı nasıl yönetilir?

   Konteyner orkestrasyon araçları (Kubernetes) için Persistent Volume Claims (PVC) kullanılır. Cloud sağlayıcılarının esnek disk çözümleri (EBS, Managed Disks) bu süreci otomatikleştirir.

7. Bir monolit veritabanı nasıl bölünür?

   Önce monolit içinde mantıksal ayrıştırma yapılır, ardından "Strangler Pattern" kullanılarak servisler ve verileri adım adım dışarı çıkarılır.

8. Ekiplerin veritabanı yönetimi bilmesi gerekir mi?

   Evet, Data Microservices dünyasında ekipler "Full-stack + Data" yetkinliğine sahip olmalıdır.

Anahtar Kavramlar Sözlüğü

Saga Orchestrator

Dağıtık bir işlem akışını yöneten, her adıma onay veren veya hata durumunda iptal emirlerini dağıtan merkezi bileşen.

Eventual Consistency (Nihai Tutarlılık)

Veri güncel durumunun tüm düğümlere hemen değil, kısa bir süre sonra yansıması durumu.

CDC (Change Data Capture)

Veritabanındaki değişimleri (INSERT/UPDATE/DELETE) izleyip anında event'e dönüştüren teknoloji.

Idempotency Key

Bir isteği benzersiz kılan anahtar. Aynı anahtarla gelen ikinci istek işlenmez, sistem durumu korunur.

Sidecar Database

Servisin ana veritabanı dışında, yerel hız veya cache amaçlı kullandığı yardımcı veri birimi.

Öğrenme Yol Haritası (Data Microservices Uzmanı Olmak)

1. Adım 1: Mikroservis Temelleri. Haberleşme türlerini (Sync vs Async), REST, gRPC ve Message Brokers (Kafka) dünyasını kavrayın.
2. Adım 2: Domain-Driven Design (DDD). Agregalar, Entity'ler ve Value Object'ler arasındaki farkları ve Bounded Context sınırlarını belirlemeyi öğrenin.
3. Adım 3: Dağıtık Veri Desenleri. Saga (Orchestration & Choreography), CQRS ve Event Sourcing pratikleri yapın.
4. Adım 4: Poliglot Veritabanı Kültürü. SQL dışında en az bir NoSQL (MongoDB, DynamoDB) ve bir Stream (Kafka Streams) teknolojisine hakim olun.
5. Adım 5: Gözlemlenebilirlik (Observability). Dağıtık sistemlerin izlenmesi, loglanması ve tracing süreçlerinde (ELK, Prometheus, Jaeger) uzmanlaşın.