Event Sourcing Nedir? Olay Tabanlı Mimari Rehberi
Geleneksel yazılım sistemleri, verinin sadece son durumunu saklar. Bir kullanıcının bakiyesi 500 TL ise, veritabanında sadece "500" yazar. Oraya nasıl gelindi? Bilinmez.
Event Sourcing bu yaklaşımı kökünden değiştirir: Her değişikliği bir olay olarak kaydeder.
Event Sourcing Temel Kavramı
Event Sourcing'de durum (state) doğrudan saklanmaz. Bunun yerine, duruma yol açan tüm olaylar kronolojik sırayla saklanır:
Event 1: HesapAçıldı { kullanıcı: "Ali", tarih: "2026-01-01" }
Event 2: ParaYatırıldı { miktar: 1000, tarih: "2026-01-05" }
Event 3: ParaÇekildi { miktar: 300, tarih: "2026-01-10" }
Event 4: ParaYatırıldı { miktar: 200, tarih: "2026-01-15" }
Mevcut bakiye? Olayları baştan sola oynatarak hesaplanır: 0 + 1000 - 300 + 200 = 900 TL
Neden Event Sourcing?
1. Tam Denetim İzi (Audit Trail)
Her değişiklik kaydedilir. Kim, ne zaman, ne değiştirdi? Tüm cevaplar olaylarda. Özellikle finans, sağlık ve hukuk alanlarında vazgeçilmezdir.
2. Zamanda Yolculuk
Herhangi bir andaki durumu yeniden oluşturabilirsiniz. "3 ay önce bu müşterinin bakiyesi neydi?" sorusuna anında cevap verebilirsiniz.
3. Hata Ayıklama Kolaylığı
Bir bug bulduğunuzda, olayları tekrar oynatarak sorunun tam olarak nerede oluştuğunu tespit edebilirsiniz.
4. Gevşek Bağlılık
Olaylar, sistemler arası iletişim için mükemmel bir arayüzdür. Bir servisin ürettiği olayı, başka servisler dinleyebilir — birbirlerini bilmeden.
Event Sourcing vs Geleneksel CRUD
| Özellik | Geleneksel CRUD | Event Sourcing | |---------|----------------|----------------| | Veri saklama | Son durum | Tüm olaylar | | Geçmiş | Yok | Tam | | Sorgu | Doğrudan | Projection gerekli | | Karmaşıklık | Düşük | Yüksek | | Denetim izi | Ekstra efor | Doğal | | Depolama | Az | Daha fazla |
Event Sourcing + CQRS
Event Sourcing genellikle CQRS (Command Query Responsibility Segregation) ile birlikte kullanılır:
- Command tarafı — Olayları yazar (Event Store'a)
- Query tarafı — Olaylardan oluşturulan projeksiyon tabloları üzerinden okur
Bu ayrım, yazma ve okuma işlemlerinin bağımsız ölçeklenmesini sağlar.
Ne Zaman Kullanılmalı?
✅ Uygun Senaryolar
- Finans sistemleri — Her işlem kaydedilmeli
- E-ticaret sipariş takibi — Siparişin her aşaması
- IoT veri akışları — Sensör verilerinin kronolojik kaydı
- İşbirliği araçları — Google Docs tarzı eşzamanlı düzenleme
❌ Uygun Olmayan Senaryolar
- Basit CRUD uygulamaları
- Geçmiş veriye ihtiyaç olmayan sistemler
- Prototip ve MVP'ler
Pratik Örnek: Sipariş Sistemi
SiparişOluşturuldu { id: "S001", ürünler: [...], tarih: "..." }
ÖdemeAlındı { siparişId: "S001", miktar: 250, yöntem: "kredi kartı" }
SiparişHazırlandı { siparişId: "S001", hazırlayan: "Depo-A" }
KargolaGönderildi { siparişId: "S001", takipNo: "TR123456" }
TeslimEdildi { siparişId: "S001", teslimTarih: "..." }
Bu olay akışı sayesinde:
- Siparişin hangi aşamada olduğunu bilirsiniz
- Sorun yaşandığında tam olarak nerede tıkandığını görürsünüz
- İstatistikler çıkarabilirsiniz (ortalama teslimat süresi vb.)
Event Store Teknolojileri
| Teknoloji | Özellik | |-----------|---------| | EventStoreDB | Özel amaçlı, en olgun çözüm | | Apache Kafka | Yüksek hacimli olay akışları | | PostgreSQL | Append-only tablo ile basit implementasyon | | DynamoDB | AWS ekosisteminde |
Sonuç
Event Sourcing güçlü bir mimari desendir, ancak her proje için uygun değildir. Karmaşıklık getirir, ancak denetim izi, zamanda yolculuk ve gevşek bağlılık gibi güçlü avantajlar sunar.
Event Sourcing ve diğer mimari desenleri interaktif olarak öğrenmek için LabLudus platformunu ziyaret edin. Yazılım Mimarisi 3.0 kitabının Bölüm 4-6'sında dağıtık sistem desenlerini detaylı olarak inceliyoruz.