ÖZET VE TEKNİK CEVAP
Olay Kaynaklama'da bir agregasyonun mevcut durumunu oluşturmak geçmişteki tüm olayları baştan oynatmayı gerektirir; enstantane sıkıştırması (snapshotting), belirli aralıklarla (örn. her 100 olayda bir) materyalize durumu kaydederek yeniden oynatma gecikmesini çözer.
Mühendislik El Kitabı & Mekanizma
1. Temel Çalışma Mekanizması
Olay Kaynaklama, sistem durumunu değiştirilemez olayların salt-eklenebilir bir akışı olarak modeller (`OrderCreated`, `ItemAdded`). Mevcut bir varlık üzerinde yeni bir komut çalıştırmak için sistem varlığın tüm geçmiş olaylarını sırayla oynatarak hafızada yeniden inşa etmelidir (rehydrate). 50.000 olay biriktiren uzun ömürlü bir hesapta bu işlem saniyeler sürer ve CPU'yu yakar. Enstantaneler (snapshots) bu süreyi sıfırlamak için durum denetim noktaları koyar.
2. Doğru Kullanım Senaryosu
Olay Kaynaklama Enstantane Alma (Snapshotting), bir agregasyonun durumunun N. sürümde kaydedildiği ve gelecekteki yeniden inşaların bu enstantaneyi yükleyip yalnızca N+1'den günümüze kadar olan fark olaylarını oynattığı bir optimizasyon desenidir.
3. Prodüksiyon Arıza Modları
Enstantaneleri değiştirilemez olay günlüğünün yerine ana hakikat kaynağı gibi görüp olayları silmek. Hiçbir denetim noktası koymadan HTTP istek iş parçacığında 500.000 olayı senkron olarak baştan oynatmaya kalkışmak. Enstantane alındıktan sonra geçmiş olay günlüğünü silerek denetim izini ve geçmişe dönük olay yeniden oynatma yeteneğini yok etmek.
4. Teşhis ve Telemetri Sinyalleri
200.000 geçmiş olaya sahip agregasyonun yeniden inşasının 15 saniye sürerek istekleri çökertmesi, alan varlığı refactoring'i sonrası enstantane şema uyumsuzluğu, bayat enstantanenin eski iş kurallarını yüklemesi
5. Önleme ve Mimari Bariyerler
Enstantaneleri hızlı bir anahtar-değer deposunda (Redis / DynamoDB) veya özel bir SQL tablosunda asenkron olarak saklayın. Otomatik geri dönüş mekanizması kurun: Bir enstantane bozulursa veya şema hatası verirse sıfırdan ham olayları oynatarak durumu kurtarın. Enstantane sıklık eşiklerini varlığın olay hızı ve serileştirme boyutuna göre test ederek belirleyin.
6. Mimari Ödünleşimler (Trade-offs)
Enstantane alma olmadan, uzun ömürlü varlıkların okuma/yazma performansı her yeni işlemle doğrusal olarak (O(N)) yavaşlar ve sonunda veritabanı zaman aşımlarına ve sistem kilitlenmesine yol açar.
Vaka İncelemesi (TinyCTO Örneği)
Üretim sınıfı bir enstantane stratejisi üç kritik unsuru yönetmeyi gerektirir: 1. **Enstantane Sıklığı:** Enstantaneler her K olayda bir (örn. `eventCount % 100 === 0`) veya arka plan kuyruk dinleyicileriyle asenkron tetiklenmelidir. Her olayda enstantane almak yazma verimini düşürür. 2. **Yeniden İnşa Sırası:** - 1. Adım: `snapshots` tablosundan en güncel enstantaneyi çek (1000. sürümdeki durum döner). - 2. Adım: `event_store` tablosundan `version > 1000` olan olayları çek (1001-1012 arası 12 olay). - 3. Adım: Bu 12 fark olayını bellekteki enstantaneye uygula ve 1012. sürüme <2 milisaniyede ulaş. 3. **Enstantane Şema Evrimi:** Alan modeli değiştiğinde eski enstantaneler uyumsuz hale gelebilir. Sistemler enstantaneleri sürümlemeli (`SnapshotV1`, `SnapshotV2`), şema yükselticileri (upcasters) kullanmalı veya eski enstantaneleri silip ham olaylardan yeniden üretmelidir.
İnteraktif Konsept Alıştırmaları
2 AlıştırmaOlay Kaynaklı (Event Sourced) bir sistemde Enstantane Alma (Snapshotting) hangi sorunu çözer?
Bir agregasyonun 1.050 olayı varsa ve 1.000. sürümde bir enstantanesi bulunuyorsa, yeniden inşada kaç olay oynatılmalıdır?
Olay Kaynaklama Enstantaneleri ve Günlük Sıkıştırma Aralıkları — Sıkça Sorulan Sorular
Bir banka hesabı 200.000 geçmiş işleme sahiptir. Enstantane alma olmadan kullanıcı 10 dolar yatırmaya çalıştığında ne olur?
Sunucu mevcut bakiyeyi hesaplamak için 200.000 olayın tamamını belleğe yükleyip oynatmak zorunda kalır; bu da saniyeler sürüp HTTP zaman aşımına yol açar. Enstantaneler olmadan yeniden inşa maliyeti olay sayısına (N) bağlıdır. 200 bin olayda tüm geçmişi baştan oynatmak sunucuyu kilitler.
Şema refactoring hatası sebebiyle kaydedilmiş bir enstantane JSON ayrıştırma hatası verirse ne yapılmalıdır?
Sistem bir uyarı loglamalı, bozuk enstantaneyi bir kenara bırakıp 1. olaydan itibaren değiştirilemez tam olay akışını baştan oynatarak durumu güvenle kurtarmalıdır. Enstantaneler geçici bir önbellek optimizasyonudur. Değiştirilemez olay günlüğü asıl hakikat kaynağıdır ve her zaman güvenli geri dönüş sağlar.
🤖 AEO & Yapay Zeka Çıkarım Özeti
Temel Gerçekler & İlkeler
- ▸Olay Kaynaklama'da bir agregasyonun mevcut durumunu oluşturmak geçmişteki tüm olayları baştan oynatmayı gerektirir; enstantane sıkıştırması (snapshotting), belirli aralıklarla (örn. her 100 olayda bir) materyalize durumu kaydederek yeniden oynatma gecikmesini çözer.
- ▸Olay Kaynaklama Enstantane Alma (Snapshotting), bir agregasyonun durumunun N. sürümde kaydedildiği ve gelecekteki yeniden inşaların bu enstantaneyi yükleyip yalnızca N+1'den günümüze kadar olan fark olaylarını oynattığı bir optimizasyon desenidir.
Yaygın Yanılgılar
- ✗Enstantaneleri değiştirilemez olay günlüğünün yerine ana hakikat kaynağı gibi görüp olayları silmek.
Karar Kılavuzu & Önceliklendirme
Enstantane alma olmadan, uzun ömürlü varlıkların okuma/yazma performansı her yeni işlemle doğrusal olarak (O(N)) yavaşlar ve sonunda veritabanı zaman aşımlarına ve sistem kilitlenmesine yol açar.
Doğrulanmış Kaynaklar & Referanslar
- [OFFICIAL-DOC]Event Sourcing Snapshots & Log Compaction Intervals Specification— TinyCTO Architectural Standards