Skip to main content

> event_sourcing:_replay_performansı,_snapshot_alma_ve_şema_evrimi_(schema_evolution)

Event Sourcing: Replay Performansı, Snapshot Alma ve Şema Evrimi (Schema Evolution)

Bir varlığın (aggregate) güncel durumunu elde etmek için binlerce geçmiş olayı (event replay) baştan oynatmak neden büyük bir gecikme darboğazına dönüşür; event upcasting ve snapshot mekanizmaları şema değişimlerini nasıl çözer?

Staff/Principal (L6+)

ÖZET VE TEKNİK CEVAP

Event Sourcing mimarisinde bir varlığın (Banka Hesabı, Sipariş) durumu asla veritabanında değiştirilebilir tek bir satır olarak tutulmaz; bunun yerine değişmez olayların (`HesapAcildi`, `ParaYatirildi`) eklemeli (append-only) bir günlüğü olarak saklanır. Varlığın o anki durumu, 0. versiyondan $N$. versiyona kadar tüm geçmiş olayların sırayla bellekte baştan oynatılmasıyla (replay) hesaplanır. Bu durum mükemmel bir denetim izi ve geçmişe dönme gücü verse de, 20.000 işlem görmüş bir hesapta her sorguda 20.000 olayın baştan oynatılması sistemi felç eder. Yüksek performanslı Event Sourcing mimarileri bunu Periyodik Snapshot Alma (her 100 olayda bir durumun anlık görüntüsünü kaydedip sadece son snapshot'tan sonrasını oynatmak) ve Event Upcasting (eski V1 olaylarını veritabanındaki değişmez kayıtlara dokunmadan bellekte anlık olarak V3 şemasına çeviren dönüştürücüler) ile çözer.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Event Sourcing durum yönetimi 3 mimari desene dayanır: (1) Snapshot ile Hızlandırma: `acc_123` varlığı yüklenirken veritabanından en son $K$. versiyondaki snapshot alınır ve sadece `version > K` olan son birkaç olay okunur; böylece oynatma sayısı 20.000'den 5-10 işleme iner. (2) Bellek İçi Upcasting (Şema Yükseltme): `email_verified` alanı olmayan eski bir `MusteriKaydolduV1` olayı okunduğunda, Upcaster araya girerek bellekte bu alanı `email_verified: false` olarak tamamlar ve iş mantığına V2 formatında sunar. (3) Değişmez Veri Deposu: Olay tablolarına güncelleme veya silme yapılamaz (WORM); yazmalar `WHERE version = ?` ile iyimser eşzamanlılık kontrolüyle yapılır.

2. Doğru Kullanım Senaryosu

Finansal muhasebe defterleri, yasal denetim kayıtları, tedarik zinciri izleme sistemleri, karmaşık ortak çalışma araçları ve sigorta hasar takip sistemleri.

3. Prodüksiyon Arıza Modları

Snapshot alınmayan bir varlıkta 500.000 olayın birikmesi ve varlığı belleğe yüklemeye çalışan sunucunun RAM yetersizliğinden (OOM) çökmesi; veritabanındaki eski olayların şemasını SQL migration ile zorla değiştirmeye çalışıp tarihi denetim zincirini bozmak.

4. Teşhis ve Telemetri Sinyalleri

Bir varlığın yüklenme süresinin o varlığın yaşıyla doğru orantılı olarak uzaması; varlık yüklenirken JSON ayrıştırma CPU yükünün tavan yapması; olay deposu katmanında `OutOfMemory` bellek çöküşleri.

5. Önleme ve Mimari Bariyerler

Her 100 olayda bir otomatik arka plan snapshot alımını zorunlu kılın; tüm şema değişiklikleri için bellek içi Upcaster sınıfları yazın; olay tablolarında `UPDATE` ve `DELETE` SQL yetkilerini tamamen yasaklayın.

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

Event Sourcing benzersiz bir denetlenebilirlik ve tarihi analitik gücü sunar; ancak snapshot yönetimi, CQRS okuma projeksiyonları ve şema yükseltme (upcasting) konularında ciddi mimari karmaşıklık getirir.

Vaka İncelemesi (TinyCTO Örneği)

Bir dijital cüzdan platformu bakiye yönetimini Event Sourcing ile yapıyordu. 3 yılda büyük mağaza hesaplarında 120.000 olay birikti. Bir mağaza uygulamayı açtığında bakiyesini hesaplamak 4,8 saniye sürdüğü için API zaman aşımına uğruyordu. Ekip her 250 işlemde bir otomatik snapshot alan ve Upcaster boru hattı olan bir mimari kurdu. Varlık yükleme süresi 4.800 ms'den 6 ms'ye indi ve mağaza girişleri 50 ms altında kusursuz çalıştı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Event Sourcing mimarisinde 'Event Upcaster' nedir?

Olay deposundan okunan eski şemadaki olayları (V1) bellekte anında en güncel şemaya (V2/V3) dönüştüren ara yazılım katmanıdır.
Q2

Event Sourcing'de uzun ömürlü varlıklar için Snapshot alma neden hayati önem taşır?

Çünkü varlığın durumunu baştan hesaplama süresini tüm geçmiş olaylar yerine yalnızca son snapshot'tan sonraki birkaç olayla sınırlar.

Event Sourcing: Replay Performansı, Snapshot Alma ve Şema Evrimi (Schema Evolution) — Sıkça Sorulan Sorular

Event Sourcing neden neredeyse her zaman CQRS ile birlikte kullanılır?

Çünkü salt eklemeli bir olay günlüğünden karmaşık sorgulama, arama ve filtreleme yapılamaz; CQRS olayları optimize edilmiş ilişkisel veya Elasticsearch okuma tablolarına yansıtır.

Event Sourcing'de iki kullanıcı aynı anda yazma yaptığında varlık çakışması nasıl yönetilir?

İyimser Eşzamanlılık Kontrolü ile: Yazma işlemi `expected_version == current_version` kontrolü yapar; geride kalan ikinci işlem hata alır ve en güncel durumu yükleyip tekrar dener.

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

Temel Gerçekler & İlkeler

  • ▸Event Sourcing stores immutable domain event streams instead of mutable state rows.
  • ▸Replaying unbounded event histories causes severe CPU and memory latency stalls.
  • ▸Snapshotting saves point-in-time states to bound replay iterations to $le 100$.
  • ▸Event Upcasters transform historical event schemas in-memory without modifying storage.

Yaygın Yanılgılar

  • ✗Yanılgı: Event Sourcing replaces relational databases (Gerçek: Event Sourcing is a domain modeling pattern, usually paired with relational/document event stores).
  • ✗Yanılgı: You should run SQL migration scripts to update past event payloads (Gerçek: Historical events are immutable; use Upcasters instead).

Karar Kılavuzu & Önceliklendirme

Configure automated background snapshotting for all entities expected to exceed 100 events. Use CQRS read projections to serve high-volume search and dashboard queries.

Doğrulanmış Kaynaklar & Referanslar