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

1. Temel Çalışma Mekanizması

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

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ı

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

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

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)

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 Örneği)

Servis başına veritabanı desenini hayata geçirmek üç temel dağıtık sistem problemini çözmeyi gerektirir: 1. **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. 2. **Ç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. 3. **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.

Servis Başına Veritabanı ve Ortak Veritabanı Ödünleşimleri — Sıkça Sorulan Sorular

Şirketiniz monolitik bir veritabanını mikroservis veritabanlarına bölmek istiyor. Hangi yetenek kökten KAYBEDİLECEK ve yeniden tasarlanması gerekecektir?

Servisler arası atomik çoklu tablo SQL işlemleri (ACID) ve bildirimsel Yabancı Anahtar (FK) kısıtlamaları. Veritabanı sınırları ayrıldığında tek düğümlü ilişkisel yabancı anahtar bütünlüğü ve ACID kilit mekanizmaları kaybolur; yerini Saga ve olay güdümlü tutarlılık alır.

Bir geliştirici, API yazmaktan kaçınmak için monolit veritabanının salt-okunur bir kopyasını oluşturup 10 mikroservisin tümüne doğrudan SQL erişimi vermeyi öneriyor. Buradaki tehlike nedir?

Şema değişikliklerinin alt servisleri çökertmeye devam ettiği ve servis özerkliğini yok eden bir Dağıtık Monolit yaratır. Doğrudan veritabanı erişimi iş mantığı doğrulamasını baypas eder, iç şemayı dışarı açar ve tüm servisleri ortak tablo yapılarına zincirleyerek dağıtım kilitlenmesi yaratır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸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.
▸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.

Yaygın Yanılgılar

✗A servisinin B servisinin veritabanına salt-okunur veritabanı kullanıcısıyla doğrudan bağlanmasına izin vermek.

Karar Kılavuzu & Önceliklendirme

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL-DOC]Database-per-Service vs Shared Database Trade-offs Specification— TinyCTO Architectural Standards

İlgili Kavramlar

https://tinycto.tv/topics/software-architecture https://tinycto.tv/incidentpedia