DEV Community

Cover image for Bölüm 2: Event Pipeline Tasarımı: Kafka’dan Lakehouse’a Gerçek Zamanlı Veri Yaşam Döngüsü
Tayfun Yalcinkaya
Tayfun Yalcinkaya

Posted on

Bölüm 2: Event Pipeline Tasarımı: Kafka’dan Lakehouse’a Gerçek Zamanlı Veri Yaşam Döngüsü

#kafka #streaming #dataengineering #turkish

İlk yazıda Event Driven Architecture’ın temel kavramlarını, Kafka üzerinde topic/channel tasarımını, event-command ayrımını, schema contract’ları ve producer-consumer ilişkisini ele aldık. Bu yazıda odağı bir adım ileri taşıyıp event’in platform içindeki yaşam döngüsüne bakacağız.

Çünkü EDA tasarımında asıl zorluk yalnızca event üretmek değildir. Asıl mesele, üretilen event’in güvenilir, izlenebilir, tekrar işlenebilir, zenginleştirilebilir ve farklı tüketiciler tarafından kullanılabilir hale gelmesidir.

Bu yazıda şu sorulara odaklanacağız:

  • Ham event platforma geldiğinde ne olur?
  • Event nasıl doğrulanır, zenginleştirilir ve tüketilebilir hale gelir?
  • Raw, validated, enriched ve curated topic’ler nasıl konumlandırılmalıdır?
  • Bu yapı modern lakehouse mimarilerindeki Medallion yaklaşımıyla nasıl ilişkilendirilebilir?
  • DLQ ve alert topic’leri ne zaman devreye girer?
  • Replay, idempotency, monitoring, security ve governance nasıl düşünülmelidir?

Event Pipeline Nedir?

EDA mimarilerinde özellikle data platform projelerinde event’ler genellikle bir yaşam döngüsünden geçer.

Bu yaşam döngüsü şöyle modellenebilir:

raw -> validated -> enriched -> curated
                  |             |
                  v             v
                 dlq          alert
Enter fullscreen mode Exit fullscreen mode

Bu yapı, veri akışının aşama aşama olgunlaşmasını sağlar.

Raw topic kaynaktan gelen ham event’i taşır. Validated topic schema ve temel kalite kontrollerinden geçmiş event’leri içerir. Enriched topic event’in referans veriler veya başka veri kaynaklarıyla zenginleştirilmiş halidir. Curated topic ise tüketiciler için güvenilir, normalize edilmiş ve iş anlamı netleşmiş event’leri temsil eder.

Event Pipeline ve Medallion Architecture İlişkisi

Bu yapı, modern lakehouse mimarilerinde sık kullanılan Medallion yaklaşımıyla doğal bir benzerlik taşır.

Lakehouse tarafında Bronze katmanı ham veriyi, Silver katmanı temizlenmiş ve zenginleştirilmiş veriyi, Gold katmanı ise iş tüketimine hazır veri ürünlerini temsil eder. Kafka üzerindeki raw, validated, enriched ve curated topic’leri de benzer bir olgunlaşma mantığını akan veri üzerinde uygular.

Ancak burada önemli bir ayrım vardır: Kafka tarafında bu aşamalar event channel olarak çalışır; lakehouse tarafında ise kalıcı, sorgulanabilir ve yönetişime tabi veri setlerine dönüşür.

Bunu şöyle düşünebiliriz:

Kafka raw topic       -> Lakehouse bronze table
Kafka enriched topic  -> Lakehouse silver table
Kafka curated topic   -> Lakehouse gold table
Enter fullscreen mode Exit fullscreen mode

Bu birebir ve zorunlu bir eşleştirme değildir. Her topic’in lakehouse üzerinde ayrı bir tabloya dönüşmesi gerekmez. Ama mimari düşünce olarak iki taraf da verinin ham halden güvenilir ve tüketilebilir hale gelmesini hedefler.

Daha doğru ayrım şu şekildedir:

Data in motion: Kafka topics
Data at rest: Lakehouse tables
Enter fullscreen mode Exit fullscreen mode

Kafka gerçek zamanlı akış, tüketici bağımsızlığı, fan-out, düşük gecikme ve replay kabiliyeti sağlar. Lakehouse ise kalıcı saklama, tarihsel analiz, SQL erişimi, BI/ML tüketimi, veri yönetişimi ve analitik veri ürünleri için konumlanır.

Raw Topic

Raw topic, kaynaktan gelen ham event’in yazıldığı ilk kanaldır.

raw.payment.transaction
Enter fullscreen mode Exit fullscreen mode

Bu aşamada veri kaynaktan geldiği şekliyle saklanır. Format bozuk olabilir, eksik alanlar olabilir, beklenen schema ile tam uyumlu olmayabilir. Raw katmanı özellikle replay, audit ve troubleshooting için değerlidir.

Raw topic, lakehouse tarafında bronze katmana yazılacak event’lerin de kaynağı olabilir. Bu sayede streaming tarafındaki event akışı ile analitik taraftaki ham veri arşivi arasında bağ kurulmuş olur.

Validated Topic

Validated topic, schema ve temel veri kalite kontrollerinden geçmiş event’leri içerir.

validated.payment.transaction
Enter fullscreen mode Exit fullscreen mode

Bu aşamada tipik kontroller şunlardır:

  • Zorunlu alanlar var mı?
  • Event schema’ya uygun mu?
  • Tarih, sayı ve para birimi formatları doğru mu?
  • Event ID var mı?
  • Event zamanı geçerli mi?
  • Duplicate kontrolü gerekiyor mu?

Raw topic’i tüketen bir validation-service, başarılı event’leri validated topic’e, hatalı event’leri ise DLQ topic’e yazabilir.

raw.payment.transaction
        |
        v
validation-service
        |
        +--> validated.payment.transaction
        +--> dlq.payment.transaction.validation
Enter fullscreen mode Exit fullscreen mode

Validated topic, downstream işlemlerin ham ve güvenilmez veriyle doğrudan çalışmasını engeller.

Enriched Topic

Enriched topic, doğrulanmış event’in ek bilgilerle zenginleştirilmiş halidir.

enriched.payment.transaction
Enter fullscreen mode Exit fullscreen mode

Örneğin raw event içinde sadece müşteri ID ve işlem bilgisi olabilir:

{
  "transaction_id": "T1001",
  "customer_id": "C789",
  "merchant_id": "M456",
  "amount": 950,
  "currency": "TRY"
}
Enter fullscreen mode Exit fullscreen mode

Enrichment sonrası event’e müşteri segmenti, merchant category, ülke, risk skoru veya lokasyon bilgisi eklenebilir:

{
  "transaction_id": "T1001",
  "customer_id": "C789",
  "customer_segment": "premium",
  "merchant_id": "M456",
  "merchant_category": "electronics",
  "country": "TR",
  "amount": 950,
  "currency": "TRY",
  "risk_score": 42
}
Enter fullscreen mode Exit fullscreen mode

Bu aşamada consumer artık sadece veri taşımaz; başka kaynaklarla join, lookup veya referans veri eşleştirmesi yapar.

Lakehouse perspektifinden enriched event’ler çoğu zaman silver katman için anlamlı bir girdidir. Çünkü veri artık ham halinden çıkmış, belirli kalite kontrollerinden geçmiş ve analitik açıdan daha kullanılabilir hale gelmiştir.

Curated Topic

Curated topic, tüketiciler için güvenilir, normalize edilmiş ve iş anlamı netleşmiş event’leri içerir.

curated.payment.transaction
Enter fullscreen mode Exit fullscreen mode

Curated katman, çoğu downstream tüketicinin bağlanmasını isteyeceğimiz seviyedir. BI, dashboard, data lake ingestion, machine learning feature pipeline, notification ve operational analytics gibi tüketiciler çoğunlukla curated event’leri kullanmalıdır.

Lakehouse tarafında curated event’ler gold katmandaki veri ürünlerine kaynak olabilir. Örneğin operasyonel dashboard, müşteri segment analizi, fraud KPI’ları veya ödeme başarı oranı gibi metrikler curated event’lerden üretilebilir.

Alert Topic

Alert topic, alarm, fraud, threshold breach veya anomali gibi aksiyon gerektiren event’lerin yayınlandığı kanaldır.

alert.payment.fraud
alert.machine.temperature
alert.network.anomaly
Enter fullscreen mode Exit fullscreen mode

Alert topic her zaman lineer pipeline’ın son adımı olmak zorunda değildir. Bazen validated, bazen enriched, bazen de curated topic’ten beslenen ayrı bir stream processing job tarafından üretilebilir.

Örneğin:

enriched.payment.transaction
        |
        v
fraud-detection-service
        |
        +--> alert.payment.fraud
Enter fullscreen mode Exit fullscreen mode

Alert topic’leri operational reaction için tasarlanır. Bu nedenle retention, consumer SLA, retry ve notification entegrasyonları ayrıca düşünülmelidir.

DLQ Topic

DLQ, yani Dead Letter Queue, işlenemeyen veya hatalı event’lerin gönderildiği kanaldır.

dlq.payment.transaction.validation
dlq.payment.transaction.enrichment
Enter fullscreen mode Exit fullscreen mode

DLQ sadece hatalı payload’ı değil, hata nedenini de taşımalıdır.

{
  "original_topic": "raw.payment.transaction",
  "original_partition": 3,
  "original_offset": 982133,
  "error_type": "VALIDATION_ERROR",
  "error_message": "customer_id is missing",
  "failed_at": "2026-05-13T12:30:00Z",
  "payload": {
    "transaction_id": "T1001",
    "amount": 950
  }
}
Enter fullscreen mode Exit fullscreen mode

Bu yaklaşım, sorunlu kayıtların kaybolmasını engeller ve sonradan düzeltme, inceleme veya replay yapılmasına imkan sağlar.

DLQ tasarlanmayan EDA projelerinde hatalı event’ler ya sessizce kaybolur ya da consumer tarafında sürekli retry edilerek pipeline’ın tamamını yavaşlatır.

Her Aşama Ayrı Topic Olmak Zorunda mı?

Hayır. Raw, validated, enriched ve curated aşamalarının her biri fiziksel Kafka topic olmak zorunda değildir.

Üç temel yaklaşım vardır.

1. Stage-Based Pipeline

Her aşama ayrı bir topic olarak modellenir.

raw -> validated -> enriched -> curated
Enter fullscreen mode Exit fullscreen mode

Bu model izlenebilirlik, replay, audit ve ekipler arası sorumluluk ayrımı için güçlüdür. Ancak topic sayısını ve operasyonel karmaşıklığı artırır.

2. Single Processor, Multi-Output

Tek bir stream processing job raw topic’i okur, validasyon, enrichment ve curation işlemlerini yapar, sadece sonuç topic’lerine yazar.

raw.payment.transaction
        |
        v
stream-processing-job
        |
        +--> curated.payment.transaction
        +--> alert.payment.fraud
        +--> dlq.payment.transaction
Enter fullscreen mode Exit fullscreen mode

Bu model daha az topic ve daha düşük latency sağlar. Ancak ara aşamalar görünmediği için debug ve replay daha zor olabilir.

3. Branching Pipeline

Aynı topic’ten birden fazla consumer farklı amaçlarla beslenir.

validated.payment.transaction
        |
        +--> enrichment-service
        +--> audit-sink-service
        +--> fraud-service
        +--> realtime-dashboard-service
Enter fullscreen mode Exit fullscreen mode

EDA’nın en güçlü taraflarından biri de budur: Aynı event, birden fazla bağımsız consumer tarafından farklı amaçlarla kullanılabilir.

Kafka ve Lakehouse Birlikte Nasıl Konumlanır?

İyi tasarlanmış bir EDA mimarisinde Kafka ve lakehouse birbirinin alternatifi değil, tamamlayıcısıdır.

Kafka şu amaçlarla kullanılır:

  • Event taşıma.
  • Low-latency processing.
  • Consumer fan-out.
  • Operational reaction.
  • Replay.
  • Sistemler arası gevşek bağlılık.

Lakehouse ise şu amaçlarla kullanılır:

  • Kalıcı saklama.
  • Tarihsel analiz.
  • SQL analytics.
  • BI ve dashboard.
  • Machine learning feature üretimi.
  • Governance, lineage ve veri ürünleri.

Örnek bir akış şöyle olabilir:

raw.payment.transaction
        |
        +--> bronze.payment_transaction_raw
        |
        v
validation-service
        |
        +--> validated.payment.transaction
        +--> dlq.payment.transaction
        |
        v
enrichment-service
        |
        +--> enriched.payment.transaction
        +--> silver.payment_transaction_enriched
        |
        v
curation-service
        |
        +--> curated.payment.transaction
        +--> gold.payment_transaction_analytics
        +--> alert.payment.fraud
Enter fullscreen mode Exit fullscreen mode

Bu modelde Kafka data-in-motion tarafını, lakehouse ise data-at-rest tarafını yönetir.

Aynı Senaryonun Pipeline Yolculuğu: Streaming’den Arşiv ve Analitiğe

İlk yazıda enerji dağıtım alanındaki anonimleştirilmiş saha örneğini channel-based topic tasarımı açısından ele almıştık. Aynı senaryoya bu kez event pipeline perspektifinden bakalım.

Bu mimaride farklı kaynaklardan gelen XML tabanlı sayaç ve aktivite mesajları önce güvenli bir Kafka giriş katmanında karşılandı. Güvenlik ve operasyonel izolasyon ihtiyacı nedeniyle dış kaynaklardan gelen verinin doğrudan iç platforma alınması yerine, kontrollü bir ingress yaklaşımı tercih edildi. Bu tip yapılarda dış dünyaya açık veya yarı-açık veri kabul katmanı ile kurum içi event backbone’un ayrılması, hem güvenlik hem de operasyonel yönetilebilirlik açısından önemli bir avantaj sağlar.

Akışın sonraki adımında stream processing katmanı Kafka’dan gelen mesajları okudu, XML içerikleri parse etti, anlamlandırdı ve hedef sistemlere yönlendirdi. Operasyonel süreçler için veriler ilişkisel bir veritabanına aktarılırken, ham ve tarihsel analiz ihtiyacı için ayrı bir büyük veri/arşivleme katmanı beslendi. Bu sayede aynı event akışı hem günlük operasyonel ihtiyaçlara hem de geriye dönük sorgulama ve analitik senaryolara hizmet edebildi.

Bu yapı EDA ve lakehouse ilişkisinin sahadaki karşılığına iyi bir örnektir. Kafka tarafında akan event’ler gerçek zamanlı taşıma, ayrıştırma ve tüketici bağımsızlığı sağlarken; arşiv ve analitik katman tarafında ham verinin saklanması, geçmişe dönük sorgulanması, anomali tespiti ve tahminleme gibi senaryolar desteklendi. Modern lakehouse terminolojisiyle düşünürsek, ham sayaç mesajları bronze benzeri bir arşiv katmanına, parse edilmiş ve anlamlandırılmış veriler silver benzeri bir analitik katmana, operasyonel dashboard ve raporlama çıktıları ise gold benzeri tüketim katmanlarına karşılık gelir.

Kafka raw meter topics
        |
        +--> Ham arşiv / bronze benzeri katman
        |
        v
stream processing / parsing / enrichment
        |
        +--> Operasyonel veritabanı
        +--> Arama ve geriye dönük sorgulama katmanı
        +--> Analitik ve tahminleme katmanı
        +--> Dashboard ve alert mekanizmaları
Enter fullscreen mode Exit fullscreen mode

Bu senaryoda Kafka retention süresi de mimarinin kritik parçalarından biriydi. Hedef sistemlerden biri yavaşladığında, kısa süreli erişilemez olduğunda veya bakım çalışması yapıldığında veri kaybı yaşanmaması için Kafka kontrollü bir dayanıklılık katmanı gibi çalıştı. Consumer’lar sistem tekrar sağlıklı hale geldiğinde kaldıkları offset’ten okumaya devam ederek akışı yeniden yakalayabildi. Bu, EDA’da retention ve replay tasarımının neden yalnızca teknik bir ayar değil, iş sürekliliği kararı olduğunu gösterir.

Operasyonel görünürlük de en az veri taşıma kadar önemliydi. Dağıtım şirketi ve veri tipi bazında son saniyelerde ve son saatlerde kaç mesaj geldiğinin izlenmesi, beklenen frekansta veri akışı olup olmadığının takip edilmesi ve akış kesintilerinde alert üretilmesi, platformun yalnızca çalışan değil, gözlemlenebilir bir sistem haline gelmesini sağladı.

Bu örnekteki temel çıkarım şudur: EDA, yalnızca sistemlerin Kafka’ya event yazması değildir. Güvenli veri kabul katmanı, topic tasarımı, stream processing, retention, replay, operasyonel monitoring, arşivleme ve analitik katman birlikte tasarlandığında gerçek anlamda kurumsal bir veri akışı mimarisi ortaya çıkar.

Böyle bir akışta parse edilemeyen XML mesajları, eksik sayaç bilgileri, beklenmeyen format değişiklikleri veya hedef sistem yazım hataları ana pipeline’ı durdurmamalıdır. Bu nedenle DLQ veya quarantine benzeri hata akışları, bu tip büyük ölçekli mimarilerde sonradan eklenen bir iyileştirme değil, tasarımın doğal bir parçası olarak düşünülmelidir.

Consumer Idempotency Neden Önemlidir?

Kafka tabanlı sistemlerde consumer’ların aynı event’i birden fazla kez işleyebilme ihtimali her zaman düşünülmelidir. Network hatası, retry, offset commit problemi veya uygulama restart durumlarında duplicate processing yaşanabilir.

Bu nedenle consumer tarafında idempotent tasarım yapılmalıdır.

Yani aynı event iki kez işlense bile sonuç değişmemelidir.

Örneğin ödeme event’i iki kez geldiyse müşteriye iki kez para iadesi yapılmamalıdır. Bunun için event_id, transaction_id veya business key üzerinden duplicate kontrolü yapılmalıdır.

Idempotency özellikle şu tüketicilerde kritiktir:

  • Finansal işlem yapan consumer’lar.
  • Bildirim gönderen servisler.
  • Operasyonel database’e yazan sink’ler.
  • Alert üreten sistemler.
  • Lakehouse tablolarına upsert veya merge yapan job’lar.

Replay Tasarımı

EDA’nın güçlü yanlarından biri, event’lerin belirli bir süre Kafka’da tutulması ve gerektiğinde tekrar okunabilmesidir.

Replay şu durumlarda gerekebilir:

  • Yeni bir consumer geçmiş event’leri baştan işlemek ister.
  • Hatalı bir enrichment logic’i düzeltilir ve event’ler yeniden işlenir.
  • Data lake’e eksik yazılan event’ler tekrar yüklenir.
  • Machine learning feature pipeline yeniden oluşturulur.
  • DLQ’deki kayıtlar düzeltildikten sonra tekrar akışa alınır.

Ancak replay güçlü olduğu kadar risklidir. Replay yapılırken downstream sistemlerin duplicate kayıt üretmemesi, finansal işlem gibi geri döndürülemez aksiyonların tekrar tetiklenmemesi gerekir.

Replay tasarımı için şu konular baştan düşünülmelidir:

  • Kafka retention süresi yeterli mi?
  • Raw event’ler lakehouse bronze katmanda arşivleniyor mu?
  • Consumer idempotent mi?
  • Replay ayrı consumer group ile mi yapılacak?
  • Replay edilen event’ler operasyonel aksiyonları tekrar tetikler mi?
  • Hangi topic’ler replay için güvenli kabul ediliyor?

Monitoring ve Operasyon

EDA projelerinde operasyonel görünürlük tasarımın bir parçası olmalıdır.

Takip edilmesi gereken temel metrikler:

  • Topic throughput.
  • Producer error rate.
  • Consumer lag.
  • Consumer processing time.
  • Failed event count.
  • DLQ event count.
  • Partition skew.
  • Broker disk kullanımı.
  • Replication durumu.
  • End-to-end latency.

Sadece Kafka cluster’ın ayakta olması yeterli değildir. Event’in kaynaktan çıkıp hedef tüketiciye kadar ne kadar sürede ulaştığı ve hangi aşamada beklediği izlenebilmelidir.

Bu görünürlüğü sağlayabilmek için monitoring tasarımı yalnızca altyapı metriklerine bırakılmamalıdır. Event’in kendisi de izlenebilir olmalıdır. Bunun için event payload veya event metadata içinde standart bazı alanların taşınması gerekir.

Özellikle şu alanlar event’in platform içindeki yolculuğunu takip etmek için kritik hale gelir:

event_id          -> Event’in benzersiz kimliği
event_type        -> Event tipi
event_time        -> Kaynak sistemde event’in oluştuğu zaman
source_system     -> Event’i üreten kaynak sistem
correlation_id    -> Aynı iş akışına ait event’leri ilişkilendiren kimlik
schema_version    -> Event schema versiyonu
processing_stage  -> Event’in pipeline içindeki aşaması
Enter fullscreen mode Exit fullscreen mode

Bu alanlar sayesinde bir event’in yalnızca Kafka topic’e yazılıp yazılmadığı değil, platform içinde hangi aşamalardan geçtiği de takip edilebilir.

Örneğin bir event için farklı zaman bilgileri tutulabilir:

event_time                -> Kaynak sistemde event’in oluştuğu zaman
ingestion_time            -> Kafka’ya ilk yazıldığı zaman
validation_time           -> Validation aşamasından geçtiği zaman
enrichment_time           -> Enrichment aşamasından geçtiği zaman
curation_time             -> Curated topic’e yazıldığı zaman
downstream_delivery_time  -> Hedef sisteme ulaştığı zaman
Enter fullscreen mode Exit fullscreen mode

Bu yaklaşım sayesinde end-to-end latency daha doğru ölçülebilir. Gecikmenin kaynak sistemde mi, Kafka topic’inde mi, stream processing job’ında mı, downstream sink’te mi yoksa lakehouse yazım katmanında mı oluştuğu daha net analiz edilebilir.

Pratikte monitoring tasarımı üç seviyede ele alınmalıdır:

1. Platform seviyesi
   Broker sağlığı
   Disk kullanımı
   Replication durumu
   Partition dağılımı

2. Akış seviyesi
   Topic throughput
   Consumer lag
   Failed event count
   DLQ count

3. Event lifecycle seviyesi
   End-to-end latency
   Stage latency
   Correlation ID bazlı izleme
   Event freshness
Enter fullscreen mode Exit fullscreen mode

Bu seviyedeki görünürlüğü tamamen manuel script’ler, ayrı ayrı dashboard’lar veya dağınık alarm kurallarıyla yönetmek zamanla zorlaşabilir. Özellikle enterprise ortamlarda Kafka operasyonunu destekleyen gelişmiş monitoring, observability, alerting ve governance yeteneklerine sahip platformlardan yararlanmak bu yükü azaltır.

Örneğin Cloudera Kafka, Confluent Platform veya benzer enterprise Kafka dağıtımları; topic seviyesinde izleme, consumer lag takibi, cluster sağlık kontrolleri, kapasite planlama, güvenlik entegrasyonu, audit ve operasyonel alarm yönetimi gibi konularda daha merkezi bir yönetim yaklaşımı sağlayabilir.

Buradaki amaç yalnızca metrik toplamak değil, Kafka tabanlı event akışlarını operasyonel olarak yönetilebilir hale getirmektir. Çünkü EDA mimarisinde monitoring, dashboard üzerinde birkaç grafik görmekten ibaret değildir; veri akışının sağlıklı, güvenli, izlenebilir ve SLA’lara uygun ilerlediğini sürekli doğrulama mekanizmasıdır.

Ayrıca her kritik pipeline için alarm eşikleri baştan tanımlanmalıdır. Örneğin belirli bir kaynaktan beklenen sürede veri gelmiyorsa, consumer lag belirli bir eşiği aşıyorsa, DLQ sayısı normal davranışın üzerine çıkıyorsa veya end-to-end latency SLA değerini geçiyorsa otomatik alert üretilmelidir.

Bu nedenle iyi bir EDA monitoring tasarımı yalnızca “Kafka ayakta mı?” sorusuna değil, şu sorulara da cevap verebilmelidir:

Event beklenen zamanda geldi mi?
Event doğru aşamadan geçti mi?
Hangi aşamada gecikti?
Hangi consumer geride kaldı?
Hangi topic’te hata oranı arttı?
DLQ sayısı normal davranışın dışına çıktı mı?
Curated event downstream tüketiciye zamanında ulaştı mı?
Enter fullscreen mode Exit fullscreen mode

Özellikle stage-based pipeline tasarımında her aşama için ayrı latency ve hata metrikleri izlenmelidir:

raw -> validated latency
validated -> enriched latency
enriched -> curated latency
curated -> downstream latency
Enter fullscreen mode Exit fullscreen mode

Güvenlik ve Governance

Enterprise EDA tasarımlarında güvenlik ve governance sonradan eklenmemelidir.

Dikkat edilmesi gereken başlıklar:

  • Kim hangi topic’e yazabilir?
  • Kim hangi topic’i okuyabilir?
  • Hassas veri event içinde taşınıyor mu?
  • Masking veya tokenization gerekiyor mu?
  • Event lineage takip ediliyor mu?
  • Hangi consumer hangi veriyi tüketiyor?
  • Audit log tutuluyor mu?
  • Retention regülasyonlarla uyumlu mu?
  • Lakehouse tarafında tablo erişimleri topic erişimleriyle tutarlı mı?

EDA, sadece teknik bir streaming projesi değil; veri yönetişimi, güvenlik ve operasyon disiplini gerektiren bir platform yaklaşımıdır.

Kafka tarafında topic-level access control, schema governance ve audit önemliyken; lakehouse tarafında table-level policy, lineage, data catalog ve veri sınıflandırma kritik hale gelir.

EDA’ya Nereden Başlamalı?

EDA’ya başlarken ilk hedef tüm kurumu event-driven hale getirmek olmamalıdır. Daha doğru yaklaşım, net iş değeri olan bir pilot use case seçmektir.

İyi başlangıç use case’leri:

  • Fraud detection.
  • Real-time transaction monitoring.
  • IoT sensor monitoring.
  • Customer activity tracking.
  • Payment event streaming.
  • Security log analytics.
  • Real-time operational dashboard.

İlk fazda şu çıktılar hedeflenmelidir:

  • Event domain modeli.
  • Topic naming standardı.
  • Schema standardı.
  • Producer ve consumer contract’ları.
  • Raw, validated, enriched, curated yaklaşımı.
  • DLQ ve retry stratejisi.
  • Lakehouse bronze/silver/gold eşleşme prensibi.
  • Monitoring yaklaşımı.
  • Security ve access modeli.
  • Replay stratejisi.

Örnek Referans Mimari

Basit bir EDA + lakehouse referans mimarisi şu şekilde olabilir:

Source Systems
      |
      v
Kaynak sistem adaptörleri / Custom Producers
      |
      v
Kafka Event Channels
      |
      +--> Stream Processing
      |        |
      |        +--> Validated / Enriched / Curated Topics
      |        +--> Alert Topics
      |        +--> DLQ Topics
      |
      +--> Lakehouse Bronze / Silver / Gold
      +--> Operational Database
      +--> BI / Dashboard
      +--> Machine Learning Pipelines
      +--> Notification Services
Enter fullscreen mode Exit fullscreen mode

Burada Kafka event taşıma omurgasını sağlar. Kaynak sistem adaptörleri veya custom producer uygulamaları veriyi Kafka event channel’larına taşır. Stream processing katmanı event’leri doğrulama, zenginleştirme, yönlendirme ve alert üretimi için kullanılır. Lakehouse ise kalıcı analitik veri katmanı olarak konumlanır.

Sonuç

Event Driven Architecture’da başarılı olmak için event üretmek yeterli değildir. Event’in platform içinde nasıl olgunlaştığı, nasıl doğrulandığı, nasıl zenginleştirildiği, hatalı kayıtların nasıl yönetildiği ve downstream tüketicilere nasıl güvenilir şekilde sunulduğu da en az event modelinin kendisi kadar önemlidir.

Raw, validated, enriched ve curated yaklaşımı, akan verinin platform içinde kontrollü şekilde olgunlaşmasını sağlar. Bu yapı modern lakehouse mimarilerindeki Bronze, Silver ve Gold katmanlarıyla benzer bir düşünce yapısını paylaşır. Kafka tarafında bu katmanlar event channel olarak, lakehouse tarafında ise kalıcı ve sorgulanabilir veri setleri olarak karşılık bulur.

Doğru tasarlanmış bir EDA + lakehouse mimarisi kurumlara iki önemli kabiliyeti aynı anda kazandırır: Gerçek zamanlı aksiyon ve güvenilir tarihsel analitik.

Yanlış tasarlandığında ise Kafka topic’leri, stream processing job’ları, lakehouse tabloları, DLQ’lar ve consumer’lar arasında izlenmesi zor bir karmaşa oluşur.

Bu nedenle EDA projelerine yalnızca topic açarak değil; event yaşam döngüsünü, lakehouse ilişkisini, replay stratejisini, monitoring yaklaşımını ve governance modelini birlikte tasarlayarak başlamak gerekir.

English version of this article is also available on my profile.

Top comments (0)