Servis Başına Veritabanı ve Ortak Veritabanı Ödünleşimleri

Stack: SOFTWARE ARCHITECTURE STACK →Staff/Principal (L6+)tradeoff

⚡ÖZET VE TEKNİK CEVAP

Servis başına veritabanı deseni, mikroservislere bağımsız şema evrimi ve hata izolasyonu kazandırırken; etki alanı sınırları arasında ACID işlemlerini, ilişkisel join sorgularını ve yabancı anahtar (FK) kısıtlamalarını feda etmeyi gerektirir.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Monolitten mikroservislere geçerken tek bir veritabanını paylaşmak gizli sıkı bağlar yaratır: bir ekibin kolon adını değiştirmesi veya oluşturduğu kilit çekişmesi komşu servisleri çökertir. Servis başına veritabanı kapsüllemeyi garanti eder ancak ekipleri dağıtık sorgular, nihai tutarlılık ve veri çoğaltımı yönetmeye zorlar.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Servis başına veritabanı, her mikroservisin kendi özel veri deposuna sahip olduğu ve diğer servislerin bu tablolara yalnızca yetkili API'ler veya olaylar üzerinden erişebildiği mimari bir desendir.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

A servisinin B servisinin veritabanına salt-okunur veritabanı kullanıcısıyla doğrudan bağlanmasına izin vermek. Yüksek trafik altında farklı veritabanları arasında dağıtık iki aşamalı kilit (2PC / XA) işlemlerine bel bağlamak. Okuma ağırlıklı sorgular için asenkron olay tabanlı replikasyon kurmadan veritabanlarını bölüp ağ gecikmesine boğulmak.

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

dağıtım bağımsızlığını bozan şemalar arası doğrudan veritabanı join'leri, şema geçişlerinde dağıtık kilit kaskatları, dağıtık monolit gibi davranan mikroservisler

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

Tam veri kapsüllemesini zorunlu kılın: bir servisin şeması ve veritabanı şifreleri asla diğer ekiplerle paylaşılmamalıdır. Durum değişikliklerini diğer servislerin okuma tablolarına güvenle yaymak için Değişiklik Verisi Yakalama (CDC) ve Outbox desenini kullanın. Birden fazla servis sınırını aşan tüm iş akışları için açık telafi edici eylemlere sahip Saga modelleri tasarlayın.

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Mikroservisler arasında ortak veritabanı kullanmak, servislerin onlarca ekiple koordinasyon kurmadan bağımsız dağıtılamadığı, ölçeklenemediği 'Dağıtık Monolit' tuzağının en temel kök nedenidir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Servis başına veritabanı desenini hayata geçirmek üç temel dağıtık sistem problemini çözmeyi gerektirir:

▸
Servisler Arası Veri Birleştirme (Cross-DB Join Yokluğu): Monolitte müşteri, sipariş ve stok tek bir SQL JOIN ile sorgulanır. Ayrık veritabanlarında bu işlem API kompozisyonu (BFF katmanı) veya alan olaylarını (CustomerUpdatedEvent, OrderCreatedEvent) dinleyen CQRS materyalize görünümleri ile çözülür.
▸
Çoklu Servis Atomik Yazmaları: Birden fazla servisi kapsayan iş süreçleri (ödeme alma ve stok düşme) standart BEGIN TRANSACTION kullanamaz. Ekipler telafi edici işlemlere sahip Saga orkestrasyonu veya koreografisi kurmalıdır.
▸
Poliglot Veritabanı Tercihi: Her servis kendi veri yapısına en uygun motoru seçebilir (Siparişler için PostgreSQL, Oturumlar için Redis, Sahtecilik analizi için Neo4j, Sepet için DynamoDB).

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Mikroservisler arasında paylaşılan bir veritabanı neden kritik bir anti-desen sayılır?

Görünmez çalışma zamanı bağımlılıkları, kilit çekişmeleri yaratır ve bağımsız şema geçişleri ile dağıtımları imkansız kılar.

İzole veritabanlarına sahip mikroservisler, cross-database join yapmadan verileri nasıl birleştirir?

API Gateway/BFF katmanında API kompozisyonu ile veya olay güdümlü CQRS materyalize okuma tabloları oluşturarak.