Basit bir CRUD uygulaması için event sourcing uyguladık, çünkü “doğru yol buydu.” Özellikler yerine altyapıya 6 ay harcadık.

Uygulama gereksinimleri:

  • Kullanıcı yönetimi CRUD'u
  • Günlük 500 kullanıcı
  • Denetim (audit) gereksinimi yok
  • Zamanda yolculuk gerekmiyor
  • Standart iş mantığı

Ne inşa ettik:

  • Kafka + PostgreSQL üzerinde event store — kendi başına tartışmalı bir karar: event store olarak Kafka, aggregate başına okuma sunmaz ve retention semantiği hantaldır; bu bize ek geçici çözümlere mal oldu
  • Event replay sistemi
  • Projeksiyonlar (okuma modelleri)
  • Snapshot alma
  • Sürümlenmiş event'ler
  • Saga orkestrasyonu

Harcanan süre:

  • Altyapı: 4 ay
  • Event şema tasarımı: 1 ay
  • Eventual consistency debug'ı: 1 ay
  • Gerçek iş özellikleri: 2 hafta

Tutarlılık debug'ına giden ay, tek örnekle: bir kullanıcı e-postasını değiştirdi, okuma modeli geride kaldığı için onay ekranı hâlâ eski adresi gösteriyordu, kullanıcı yeniden denedi — ve biz iki günümüzü bir projeksiyon yeniden inşası boyunca mükerrer EmailChanged event'lerinin izini sürerek geçirdik. Tek bir satırı güncelleyen bir form için.

Neye ihtiyacımız vardı:

class User:
    def update(self, data):
        self.name = data.name
        self.email = data.email
        db.save(self)

Event sourcing ne zaman mantıklıdır:

  • Düzenleyici denetim izi gereksinimleri
  • Finansal işlemler
  • Zamanda yolculukla debug
  • Çok sayıda durum geçişi olan karmaşık domain

Ders: Event sourcing güçlüdür. Aynı zamanda pahalıdır. Karmaşıklığı gereksinimlerle eşleştirin — küçük ekipleri ihtiyaç duymadıkları mikroservislere sürükleyen de aynı içgüdüdür.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #EventSourcing #Mimari #Kalıplar #Antipattern