Event sourcing son 10 yıldır mimari konferansların standart konularından. Kitaplar yazıldı, workshop’lar verildi, blog post’lar döşendi. Ama gerçek production ortamında event sourcing kullanan projelerin oranı ne?
Benim gözlemlediğim: event sourcing kullanıp da ciddi değer aldığı sistemler var ama nadir. Bu yazıda event sourcing’in gerçek kullanım alanlarını ve yaygın yanılgıları anlatacağım.
Event sourcing ne demek (tekrar)
Klasik yaklaşımda bir entity’nin current state’ini tutuyorsun. User’ın email’ini güncellediğinde database’de email column’u değişiyor.
Event sourcing’te current state’i değil, state’i değiştiren event’leri tutuyorsun: UserCreated, EmailChanged, PasswordReset, ProfileUpdated. Current state event’lerin “replay” edilmesiyle hesaplanıyor.
Teoride güzel:
– Audit log native
– Time travel (geçmişteki herhangi bir state’e dön)
– Multiple projections (aynı event’lerden farklı view’lar üret)
– Debug ve replay kolay
Pratikte?
Event sourcing gerçekten işe yaradığı 3 senaryo
1. Financial systems. Bankalar, ödeme servisleri, muhasebe sistemleri. Her transaction tarihsel olarak kaydedilmeli, audit trail zorunlu, hiçbir veri silinemez. Event sourcing bu ihtiyaçlara native cevap veriyor.
Stripe’ın backend’i event-sourced. Ledger as a source of truth. Transaction’lar append-only log’da, current balance derived state.
2. Complex workflow state machines. Order lifecycle’ı 15 farklı state’ten geçiyor: placed, validated, authorized, paid, reserved, packed, shipped, in-transit, delivered, returned, refunded, etc. Her transition audit gerektiriyor, debug için önceki state’e dönmek gerekiyor.
Bu tür sistemlerde event sourcing “bu order tam olarak ne oldu” sorusuna cevap veriyor. Normal CRUD’da sadece current state var, history’yi ayrı tabloda tutmak 2-3 kat complexity ekliyor.
3. Collaborative editing / real-time sync. Google Docs, Figma gibi sistemler. Her edit bir operation/event. Multiple client’lar aynı document üzerinde operation’lar yayınlıyor, her client kendi order’ıyla replay ediyor.
Bu operational transformation (OT) ve CRDT’lere dayanıyor, event sourcing bu mimarilerin temel bloğu.
Event sourcing yaygın yanılgıları
Yanılgı 1: “Modern systems event-sourced olmalı.”
Yanlış. Çoğu CRUD app event sourcing’ten fayda görmüyor. Blog, admin panel, basit e-commerce. State’i doğrudan güncellemek daha basit ve performant.
Yanılgı 2: “Event sourcing CQRS’in parçası.”
Yanlış. CQRS event sourcing olmadan da olabilir. Event sourcing CQRS olmadan da olabilir. Ama sıkça birlikte tartışıldıkları için birleşik anılıyor.
Yanılgı 3: “Event store scaling kolay çünkü append-only.”
Partially true. Event store yazma için scaling kolay (append-only, immutable). Ama query/projection için ağır optimizasyon gerekiyor. Milyarlarca event’i her read’de replay edemiyorsun, snapshot’lar tutmak zorundasın.
Yanılgı 4: “Event schema önemsiz.”
Event’ler 5 yıl, 10 yıl yaşıyor. Schema evolution critical. Forward/backward compatibility disciplined olmazsa sistem bir süre sonra “old event’leri deserialize edemiyor” noktasına geliyor.
Yanılgı 5: “Replay her zaman deterministic.”
Yanlış. Eğer business logic’i event replay’de dış servislere bağımlıysa (ödeme gateway’e çağrı, email gönder), replay deterministic olmuyor. Side effect’lerin idempotent olması lazım.
Küçük projede event sourcing uygulamanın maliyeti
3 kişilik bir ekip event sourcing başlattı mı?
İlk 2 ay: Her developer event store, projection, snapshot konseptlerini öğreniyor. Productivity düşük.
3-6 ay: İlk major refactor. Event schema yanlış tasarlanmıştı, migrate etmek gerekiyor. Production’da event’leri “upgrade” etmek büyük iş.
6-12 ay: Projection rebuild performance issue. Milyonlarca event replay etmek saatler sürüyor. Snapshot strategy kurmak gerekiyor.
1 yıl+: Team finally productive. Ama karmaşık bug’lar chasing.
Bu timeline çoğu projenin kaldıramayacağı investment. Tekil finansal/audit-critical system’larda değer. Genel purpose uygulamalarda overkill.
Hybrid yaklaşım: event’i log’la, state’i tut
Event sourcing’in tam karmaşıklığı olmadan benzeri fayda almanın yolu: hybrid model.
Current state’i database’e yazıyorsun (normal CRUD). Aynı zamanda önemli event’leri audit log tablosuna yazıyorsun: UserEmailChanged, SubscriptionUpgraded, PermissionGranted.
Bu yaklaşım:
– Query’ler hızlı (current state’ten okuyor)
– Audit trail var (event log’dan)
– Debug/history için replay yapılabilir (event log üzerinden)
– Full event sourcing complexity’si yok
Çoğu proje için bu hybrid yaklaşım optimal. Ben consulting projelerinde genelde bunu öneriyorum. Full event sourcing’e ancak audit/compliance zorunlu ise giriyorum.
Karar kriterleri
Gerçekten event sourcing yapmalı mıyım? Şu soruların hepsine “evet” dersen:
- Audit trail legal/compliance gereksinim mi (bankacılık, sağlık)?
- Entity lifecycle’ım 10+ state geçişi içeriyor mu?
- Debugging için “bu state’e nasıl geldi” sorusunu sık mı soruyorum?
- Multiple projection gereksinimim var mı (aynı veriden farklı view’lar)?
- Ekibim event sourcing öğrenmek için 3-6 ay yatırım yapabilir mi?
- Operational ekibim event store monitor/maintain edebilir mi?
Hepsine evet dediysen event sourcing mantıklı. Herhangi birinde hayır varsa yeniden düşün.
Event store teknolojileri
Eğer gidersen:
EventStoreDB: Event sourcing için özel built. Mature, feature-rich.
Kafka: Log olarak event store. Ama gerçek event sourcing feature’ları (snapshot, projection) için üstüne framework yazman gerekiyor.
PostgreSQL append-only tablo: Basit start için yeterli. Milyar event’e kadar çalışıyor. Sonra specialized tool’a geçebilirsin.
Marten (PostgreSQL üstüne): .NET dünyası için event sourcing library’si. PostgreSQL’i event store olarak kullanıyor.
Küçük başla. PostgreSQL + kendi snapshot logic’in. İhtiyaç doğdukça upgrade.
Sonuç
Event sourcing güçlü ama dar bir kullanım alanı var. Financial systems, complex workflows, collaborative tools. Genel purpose web app’ler için overkill.
Hybrid approach (current state + event audit log) çoğu projede event sourcing’in %80 faydasını veriyor, %30 karmaşıklığıyla. Buradan başla, gerçek ihtiyaç ortaya çıkarsa tam event sourcing’e geç.
Teknik konferanslarda gürültülü olan her pattern projen için uygun değil. Önce problem’i anla, sonra çözüm seç.