Skip to main content

> olay_taşımalı_durum_aktarımı_(ecst)_kalıbı

Olay Taşımalı Durum Aktarımı (ECST) Kalıbı

Asenkron olayların içine tam varlık durum enstantanelerini gömmek mikroservisler arasındaki senkron RPC bağımlılıklarını nasıl ortadan kaldırır ve hangi ödünleşimleri (tradeoffs) doğurur?

Stack: SOFTWARE ARCHITECTURE STACK →Staff (L6-L7)pattern

ÖZET VE TEKNİK CEVAP

İş alanı olaylarının içine sadece varlık kimliğini değil tüm nitelikleri zenginleştirilmiş olarak gömüp, alıcı servislerin kaynak servise geri dönüp senkron sorgu atmadan kendi yerel veritabanlarını güncelleyip iş mantığını yürütmesini sağlayarak.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

'Zayıf' (thin) olay bildirimlerinde (örn. `OrderPlaced { orderId: '123' }`), alıcı servisler müşteri, adres ve ürün detaylarını almak için kaynak servise anında senkron HTTP/gRPC geri arama çağrıları yapmak zorundadır. Bu durum sistemler arasında sıkı bir çalışma zamanı ve gecikme bağımlılığı yaratır. Olay Taşımalı Durum Aktarımında (ECST) ise olay yükü denormalize edilmiş tam varlık enstantanesini taşır. Tüketici servisler bu akışı dinleyip veriyi yerel depolarına yazar ve üretici servise olan tüm anlık ağ bağımlılıklarını sıfırlar.

2. Doğru Kullanım Senaryosu

Kaynak servislerin geri dönen yoğun sorgu fırtınalarını kaldıramayacağı yüksek hacimli sistemler veya üretici servis çökse bile alıcı servislerin bağımsız ve kesintisiz çalışması gereken kritik yapılar.

3. Prodüksiyon Arıza Modları

1) Sırasız Olay ile Veri Ezilmesi: v2 olayı işlendikten sonra geciken bir v1 olayının gelip güncel durumu sessizce eskiye döndürmesi; 2) Aşırı Yük Şişmesi: Olay boyutlarının megabaytlara ulaşıp Kafka broker performansını çökertmesi; 3) KVKK/GDPR Veri Sızıntısı: Hassas müşteri verilerinin onlarca yetkisiz kuyruğa kontrolsüz dağıtılması.

4. Teşhis ve Telemetri Sinyalleri

Mesaj kuyruklarındaki ortalama bayt boyutunu, sırası kaydığı için atılan olay sayaçlarını, alıcı servislerdeki yerel veri kayma oranını ve kaynak servise gelen doğrudan okuma sorgusu sayısını izlemek.

5. Önleme ve Mimari Bariyerler

Bayat güncellemeleri reddetmek için olaylara monotonik artan sürüm numarası veya zaman damgası ekleyin; hassas veriler için alan bazlı şifreleme uygulayın ve olay yüklerindeki sınırsız dizi alanlarını kırparak boyutu kontrol altında tutun.

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

Eksiksiz servis bağımsızlığı sağlar ve servisler arası sorgu gecikmesini sıfırlar; buna karşılık veri kopyalama (duplication), yüksek ağ bant genişliği tüketimi ve nihai tutarlılık gecikmesi getirir.

Vaka İncelemesi (TinyCTO Örneği)

TinyCTO Bölüm 118: Black Friday sırasında Bildirim Servisi, yalnızca sipariş kimliği içeren olaylardan adres çözümlemek için Kullanıcı Servisine saniyede 80.000 HTTP isteği attı ve ana veritabanını kilitledi. ECST modeline geçilerek adresler doğrudan olay içine gömüldü ve servisler arası HTTP çağrıları sıfıra indirildi.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

'Olay Bildirimi' (Event Notification) ile 'Olay Taşımalı Durum Aktarımı' (ECST) arasındaki temel fark nedir?

Olay Bildirimi yalnızca temel kimlikleri (ID) gönderip tüketicinin üreticiyi sorgulamasını gerektirir; ECST ise tam varlık durumunu göndererek tüketicinin bağımsız çalışmasını sağlar.
Q2

Tüketiciler ECST kalıbında sırası karışmış olayların yerel durumu bozmasını nasıl engeller?

Olaydaki sürüm numarasını veya updatedAt zaman damgasını kontrol ederek; yereldeki mevcut sürümden daha eski olan olaylar güvenle yok sayılır.
Q3

ECST kalıbında ortaya çıkan güvenlik ve regülasyon (GDPR/KVKK) zorluğu nedir?

Kişisel verilerin (PII) birden fazla kuyruğa ve yerel veritabanına yayılması, 'Unutulma Hakkı' (GDPR silme talepleri) gibi regülasyon süreçlerini yönetmeyi son derece zorlaştırır.

Olay Taşımalı Durum Aktarımı (ECST) Kalıbı — Sıkça Sorulan Sorular

Büyük ikili dosyalar (resimler veya PDF belgeleri) ECST mesaj yüküne dahil edilmeli midir?

Hayır. Asla olay kuyruklarına büyük ikili dosyalar koymayın. Dosyaları Nesne Depolama (S3/GCS) sisteminde saklayıp olaya yalnızca değiştirilemez URI ve hash bilgisini ekleyin.

Varlık şeması değiştiğinde ECST sistemin bakımını nasıl etkiler?

Birçok alt servis geniş olay yapısına bağımlı olduğu için, şema evriminin Schema Registry (Avro/Protobuf) kullanılarak kesinlikle geriye ve ileriye dönük uyumlu tutulması gerekir.

ECST ne zaman bir anti-kalıba dönüşür?

Olaylar yüzlerce gereksiz alan taşıyan hantal nesnelere dönüştüğünde veya veri gizliliği kuralları kullanıcı verisinin alt servislerde kopyalanmasını kesin olarak yasakladığında.

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

Temel Gerçekler & İlkeler

  • ▸Martin Fowler, 2017 yılında Olay Taşımalı Durum Aktarımını Olay Güdümlü Mimarinin dört temel kalıbından biri olarak tanımlamıştır.
  • ▸ECST sistem erişilebilirliğini bağımsız kılar: üretici servis çökse bile alıcı servisler kesintisiz çalışmaya devam edebilir.

Yaygın Yanılgılar

  • ✗ECST'nin alıcı servislerde veri modelleme ihtiyacını bitirdiğini sanmak; tüketiciler gelen olay yükünü yine de kendi sınırlı bağlam modellerine dönüştürmelidir.

Karar Kılavuzu & Önceliklendirme

Tüketicilerin üreticiye atacağı sorguların darboğaz yaratacağı senaryolarda ECST kullanın; verinin çok değişken, aşırı hassas olduğu veya nadiren sorgulandığı durumlarda hafif Olay Bildirimlerini tercih edin.

Doğrulanmış Kaynaklar & Referanslar