Bu yazı, Event Driven Architecture ve Kafka tabanlı event/channel tasarımını Türkçe teknik kaynak ihtiyacını da gözeterek hazırlanmış bir yazı dizisinin ilk bölümüdür.

Enterprise kurumlar, karar alma süreçlerini saatler veya günler sonra çalışan batch analitiklere bırakmak yerine, olaylar gerçekleştiği anda tepki verebilen mimarilere yöneliyor. Fraud detection, gerçek zamanlı müşteri deneyimi, IoT izleme, ödeme sistemleri, operasyonel dashboardlar ve güvenlik analitiği gibi alanlarda Event Driven Architecture (EDA), artık yalnızca modern bir entegrasyon yaklaşımı değil; gerçek zamanlı veri platformlarının temel yapı taşlarından biri haline geliyor.

Bunun nedeni basit: Birçok kurumda kronikleşen batch analitik problemleri yalnızca teknoloji problemi değil, zamanlama problemidir. Veri önce toplanır, sonra taşınır, sonra işlenir, sonra raporlanır. Ancak iş kararı çoktan gecikmiş olabilir. EDA, doğru tasarlandığında bu gecikmeyi azaltır; veriyi bekletmeden, olay gerçekleştiği anda işleyerek daha düşük latency, daha hızlı aksiyon ve daha esnek entegrasyon modeli sağlar.

Bu noktada EDA’yı batch işlemenin doğrudan alternatifi gibi değil, onu tamamlayan farklı bir mimari refleks olarak konumlandırmak daha doğru olur. Büyük tarihsel veri işleme, dönemsel raporlama, mali kapanış veya yoğun toplu dönüşüm işleri hâlâ batch dünyasının güçlü olduğu alanlardır. EDA’nın fark yarattığı yer ise verinin sürekli aktığı, kararın gecikmeden verilmesi gerektiği ve sistemlerin olaylara anlık tepki üretmesinin beklendiği senaryolardır.

Data management platformlarında yanlış tasarlanan Event Driven Architecture yaklaşımları ise zamanla streaming akışlarını ve gerçek zamanlı analitikleri tam bir karmaşaya dönüştürebilir. Başlangıçta “Kafka topic açalım, sistemler oraya yazsın” gibi basit görünen kararlar; birkaç ay sonra kontrolsüz topic büyümesi, belirsiz event sahipliği, hatalı veri yayılımı, tüketici bağımlılıkları, tekrar işleme problemleri ve izlenemeyen veri akışları olarak geri döner.

Bu yazı dizisinin omurgasını iki soru oluşturuyor: Event’i nasıl tasarlamalıyız ve event platform içinde nasıl olgunlaşmalı? İlk yazıda event’in kendisine odaklanacağız; event-command ayrımı, Kafka topic/channel modeli, schema contract, partition key, producer-consumer ilişkisi ve sık yapılan tasarım hatalarını ele alacağız. İkinci yazıda ise event’in platform içindeki yaşam döngüsüne bakacağız; raw’dan curated event’lere uzanan pipeline’ı, DLQ ve alert topic’lerini, replay, monitoring, governance ve modern lakehouse mimarilerindeki Medallion yaklaşımıyla kurulan ilişkiyi inceleyeceğiz.

Event Driven Architecture Nedir?

Event Driven Architecture, sistemlerin birbirleriyle doğrudan ve senkron çağrılar üzerinden değil, gerçekleşen olaylar üzerinden haberleştiği bir mimari yaklaşımdır.

Bir event, sistemde gerçekleşmiş anlamlı bir iş olayını temsil eder:

• Müşteri oluşturuldu.
• Ödeme tamamlandı.
• Kart işlemi başarısız oldu.
• Stok seviyesi kritik eşiğin altına düştü.
• Sensör sıcaklığı limit değerini aştı.
• Kullanıcı mobil uygulamaya giriş yaptı.

Buradaki önemli nokta şudur: Event bir istek değil, gerçekleşmiş bir durum bilgisidir.

Örneğin:

PaymentCompleted
CustomerCreated
OrderShipped
MachineTemperatureExceeded

Bunlar event’tir. Çünkü geçmişte olmuş bir şeyi bildirirler.

Buna karşılık:

CreatePayment
UpdateCustomer
SendNotification

bunlar daha çok command yapısına yakındır. Yani bir sisteme bir şey yaptırma niyeti taşır. EDA tasarımında event ile command ayrımını doğru yapmak kritik önemdedir.

Klasik Entegrasyon ile EDA Arasındaki Fark

Klasik mimarilerde sistemler genellikle birbirini doğrudan çağırır.

Application A ---> Application B ---> Application C

Bu model küçük ölçekte basit görünür. Ancak sistem sayısı arttıkça bağımlılıklar büyür. Bir servisin yavaşlaması, hata alması veya değişmesi zincirdeki diğer sistemleri de etkileyebilir.

EDA’da ise sistemler doğrudan birbirine bağımlı olmak yerine olay yayınlar ve bu olaylarla ilgilenen sistemler ilgili event’i tüketir.

Application A ---> Event Channel ---> Application B
                               |----> Application C
                               |----> Application D

Bu model sayesinde üretici sistem, event’i kimin tüketeceğini bilmek zorunda kalmaz. Yeni bir tüketici eklemek için mevcut producer uygulamayı değiştirmeye gerek kalmaz.

Kafka EDA İçinde Nerede Durur?

Kafka, EDA mimarilerinde çoğunlukla event backbone, event bus veya event streaming platform olarak konumlanır.

Kafka’nın temel kavramları şunlardır:

• Producer: Event üreten uygulama.
• Topic: Event’lerin yazıldığı mantıksal kanal.
• Partition: Topic içindeki paralel işleme birimi.
• Consumer: Event okuyan uygulama.
• Consumer Group: Aynı işi paylaşarak yapan consumer kümesi.
• Broker: Kafka cluster içindeki sunucular.
• Offset: Consumer’ın topic içinde nereye kadar okuduğunu gösteren pozisyon.
• Retention: Event’lerin Kafka üzerinde ne kadar süre tutulacağını belirleyen süre veya boyut politikası.

Basit bir Kafka tabanlı EDA akışı şöyle düşünülebilir:

Source System
     |
     v
Kafka Topic / Event Channel
     |
     +--> Real-time Analytics
     +--> Notification Service
     +--> Data Lake Ingestion
     +--> Fraud Detection
     +--> Monitoring Dashboard

Burada Kafka topic’leri, sistemler arasında event taşıyan channel’lar gibi davranır.

Channel-Based Kafka Tasarımı Ne Anlama Gelir?

Channel-based yapı, genellikle event tiplerinin veya iş domain’lerinin Kafka topic’leri üzerinden ayrıştırılması anlamına gelir.

Örneğin bir ödeme sistemi için:

payment.transaction.created
payment.transaction.authorized
payment.transaction.completed
payment.transaction.failed
payment.transaction.reversed

Müşteri domain’i için:

customer.created
customer.updated
customer.segment.changed
customer.status.changed

IoT veya üretim senaryosu için:

machine.telemetry.raw
machine.telemetry.enriched
machine.alert.temperature
machine.maintenance.predicted

Burada her topic bir event channel’dır. Producer uygulama ilgili channel’a event yazar. Consumer uygulamalar ise ilgilendikleri channel’ları okuyarak kendi işlerini yapar.

Sahadan Anonimleştirilmiş Bir Örnek: Enerji Dağıtım Verilerinde Channel-Based Tasarım

Aşağıdaki örnek, enerji dağıtım alanında yürütülmüş büyük ölçekli bir veri platformu çalışmasından anonimleştirilerek aktarılmıştır. Kurum ve proje adı paylaşmadan, sahada karşılaşılan mimari ihtiyaçları ve EDA tasarım kararlarını görünür kılmayı amaçlıyor.

Bu senaryoda temel ihtiyaç, ülke genelindeki akıllı sayaç ve aydınlatma altyapısından gelen verilerin merkezi olarak toplanması, güvenli biçimde taşınması, işlenmesi ve analiz edilebilir hale getirilmesiydi. İlk bakışta bu bir entegrasyon projesi gibi görünebilir. Ancak veri hacmi, kaynak sistem sayısı, 7/24 çalışma ihtiyacı, güvenlik beklentisi ve operasyonel izleme gereksinimi düşünüldüğünde problem aslında klasik entegrasyondan çok daha fazlasıydı: gerçek zamanlı ve kesintisiz çalışan bir veri akışı mimarisi tasarlamak gerekiyordu.

Sahada karşılaşılan en kritik kararlardan biri Kafka topic tasarımıydı. Birden fazla dağıtım şirketinden farklı tiplerde sayaç verileri alınıyordu: elektrik tüketim verileri, sayaç aktivite bilgileri, çevrim içi/çevrim dışı durumları ve operasyonel sinyaller. Tüm veriyi tek bir büyük topic’e yazmak ilk bakışta daha basit görünebilirdi; ancak bu yaklaşım consumer tarafında ayrıştırma, ölçekleme, hata yönetimi ve izleme açısından ciddi karmaşa yaratacaktı.

Bu nedenle kaynak ve veri tipi bazlı channel yaklaşımı tercih edildi. Dağıtım şirketi ve veri tipi kırılımında onlarca Kafka topic’i tasarlanarak her akışın ayrı izlenebilmesi, ayrı tüketilebilmesi ve gerektiğinde bağımsız ölçeklenebilmesi sağlandı.

Örnek olarak bu mantık şu şekilde düşünülebilir:

raw.energy.meter.reading.<source>
raw.energy.meter.status.<source>
raw.energy.lighting.consumption.<source>
raw.energy.device.activity.<source>

Bu tasarımda Kafka yalnızca mesaj taşıyan bir ara katman değil, farklı kaynaklardan gelen yüksek hacimli veriyi düzenli kanallar üzerinden ayrıştıran merkezi event backbone rolünü üstlendi. Böylece gerçek zamanlı izleme servisleri, operasyonel veritabanına yazan consumer’lar, arşivleme süreçleri ve analitik platformlar aynı veri akışından bağımsız olarak beslenebildi.

Bu örneğin gösterdiği temel ders şudur: Channel-based Kafka tasarımında topic sayısının artması tek başına problem değildir. Asıl problem, topic’lerin hangi domain’e, hangi veri tipine, hangi sahipliğe ve hangi tüketim amacına hizmet ettiğinin belirsiz olmasıdır.

Event mi Command mı?

EDA tasarımında sık yapılan hatalardan biri event ile command kavramlarını karıştırmaktır.

Event, gerçekleşmiş bir iş olayını ifade eder:

PaymentCompleted
CustomerCreated
OrderShipped

Command ise bir sisteme yapılması istenen aksiyonu ifade eder:

CreatePayment
UpdateCustomer
SendNotification

Kafka üzerinde command da taşınabilir; ancak bu durumda timeout, retry, correlation, response handling ve idempotency gibi konular daha karmaşık hale gelir. Bu nedenle Kafka tabanlı EDA tasarımında mümkün olduğunca “gerçekleşmiş olayları” modellemek daha sağlıklı bir başlangıçtır.

Business Event State ile Data Pipeline Stage Karıştırılmamalı

EDA tasarımında bir diğer kritik ayrım, business state ile data processing stage arasındadır.

Business event lifecycle şuna benzer:

PaymentInitiated -> PaymentAuthorized -> PaymentCompleted -> PaymentSettled

Data pipeline stage ise şuna benzer:

raw -> validated -> enriched -> curated

İlki iş sürecinin durum değişimini anlatır. İkincisi verinin platform içinde işlenme olgunluğunu anlatır. Bu iki kavramı ayırmak, doğru topic tasarımı için çok önemlidir.

İlk yazıda daha çok business event ve channel tasarımına odaklanıyoruz. İkinci yazıda ise raw, validated, enriched ve curated gibi data pipeline aşamalarını detaylandıracağız.

Topic Tasarımında Dikkat Edilmesi Gerekenler

Kafka üzerinde EDA tasarlarken topic isimlendirme, partition stratejisi ve sahiplik modeli en kritik kararlardandır.

Örnek topic naming standardı:

<domain>.<entity>.<event>

Örnekler:

payment.transaction.completed
customer.profile.updated
machine.temperature.exceeded

Bazı kurumlar stage bilgisini de topic adına eklemeyi tercih eder:

raw.payment.transaction.created
validated.payment.transaction.created
enriched.payment.transaction.created
curated.payment.transaction.completed

Burada önemli olan tek bir doğru isimlendirme standardı değil, organizasyon genelinde tutarlı bir standardın olmasıdır.

İyi bir topic ismi şu sorulara cevap verebilmelidir:

• Hangi domain’e ait?
• Hangi entity veya iş nesnesini temsil ediyor?
• Hangi event’i taşıyor?
• Bu topic’in sahibi hangi ekip?
• Bu topic kalıcı bir contract mı, yoksa geçici bir processing topic’i mi?

Partition Key Seçimi

Kafka’da partition key seçimi hem performansı hem de sıralama garantisini etkiler.

Örneğin ödeme işlemlerinde aynı müşteriye ait event’lerin sıralı işlenmesi gerekiyorsa key olarak customer_id seçilebilir.

Topic: payment.transaction
Key: customer_id

Aynı karta ait işlemler sıralı işlenmek isteniyorsa card_id daha doğru olabilir.

Topic: card.transaction
Key: card_id

Yanlış key seçimi bazı partition’ların aşırı yüklenmesine, bazı partition’ların ise boş kalmasına neden olabilir. Bu da hot partition problemine yol açar.

Partition key seçerken şu sorular sorulmalıdır:

• Hangi seviyede sıralama garantisine ihtiyacımız var?
• Hangi key dağılımı daha dengeli sağlar?
• Consumer paralelliği nasıl ölçeklenecek?
• Aynı business entity’ye ait event’ler aynı partition’da mı kalmalı?

Schema Yönetimi

EDA’da event contract çok önemlidir. Çünkü producer ve consumer doğrudan birbirini tanımasa bile schema üzerinden anlaşır.

Bu nedenle her event tipi için net bir schema yönetimi olmalıdır.

Dikkat edilmesi gerekenler:

• Event schema versiyonlanmalı.
• Geriye uyumluluk kuralları tanımlanmalı.
• Zorunlu ve opsiyonel alanlar net olmalı.
• Event timestamp, event_id, source_system gibi metadata alanları standartlaştırılmalı.
• Breaking change yapılacaksa yeni versiyon veya yeni topic stratejisi belirlenmeli.

Örnek metadata alanları:

{
  "event_id": "evt-12345",
  "event_type": "PaymentCompleted",
  "event_version": "1.0",
  "event_time": "2026-05-13T10:15:00Z",
  "source_system": "payment-service",
  "correlation_id": "corr-98765"
}

Schema yönetimi ihmal edilirse Kafka topic’leri zamanla güvenilir event contract’ları olmaktan çıkar ve “kim ne yazıyor, kim nasıl okuyor” sorusunun cevabı belirsizleşir.

Producer ve Consumer İlişkisi

EDA’nın en önemli avantajlarından biri producer ve consumer arasındaki gevşek bağlılıktır.

Producer uygulama, event’i yayınlar. Bu event’i kaç consumer’ın okuyacağını bilmek zorunda değildir.

payment.transaction.completed
        |
        +--> fraud-service
        +--> notification-service
        +--> data-lake-ingestion
        +--> realtime-dashboard
        +--> audit-service

Bu model yeni kullanım senaryolarının mevcut producer uygulamayı değiştirmeden eklenmesine olanak sağlar. Ancak bu özgürlük, topic sahipliği ve schema contract net değilse hızla kontrolsüz tüketici bağımlılığına dönüşebilir.

Bu yüzden her kritik topic için şu bilgiler net olmalıdır:

• Topic owner kim?
• Producer uygulama hangisi?
• Desteklenen schema versiyonları neler?
• Kimler tüketebilir?
• Retention politikası nedir?
• Breaking change süreci nasıl yönetilir?

EDA’da Sık Yapılan Tasarım Hataları

EDA projelerinin başarısız olmasının nedeni genellikle Kafka’nın yetersizliği değil, mimari kararların net olmamasıdır.

Sık yapılan hatalar şunlardır:

• Her ihtiyaç için kontrolsüz topic açmak.
• Event ile command kavramlarını karıştırmak.
• Topic sahipliğini tanımlamamak.
• Schema yönetimini ihmal etmek.
• Partition key’i rastgele seçmek.
• Retention politikasını iş ihtiyacına göre belirlememek.
• Producer ve consumer contract’larını dokümante etmemek.
• Business event state ile data pipeline stage kavramlarını karıştırmak.
• Monitoring, security ve governance gereksinimlerini sonradan düşünmek.

Sonuç

Event Driven Architecture, gerçek zamanlı veri akışları ve analitik ihtiyaçları için güçlü bir mimari yaklaşımdır. Ancak EDA’nın başarısı Kafka cluster kurmakla değil, doğru event modelini tasarlamakla başlar.

İyi bir EDA tasarımı için şu soruların cevabı net olmalıdır:

• Hangi event’ler üretilecek?
• Event ile command ayrımı nasıl yapılacak?
• Topic/channel standardı nasıl olacak?
• Topic sahipliği kimde olacak?
• Schema nasıl yönetilecek?
• Partition key nasıl seçilecek?
• Producer ve consumer contract’ları nasıl korunacak?

Bu yazıda EDA’nın temelini oluşturan event modelleme, Kafka topic/channel tasarımı, schema contract ve producer-consumer ilişkisini ele aldık. Bir sonraki yazıda ise bu event’lerin platform içinde nasıl olgunlaştığını; raw, validated, enriched ve curated akışlarını, DLQ ve alert topic’lerini, replay stratejisini, monitoring’i ve modern lakehouse mimarilerindeki Medallion yaklaşımıyla ilişkisini inceleyeceğiz.

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