Forem: Tayfun Yalcinkaya

Kafka ile Event Driven Architecture (EDA): Event ve Channel Tasarımını Doğru Yapmak

Tayfun Yalcinkaya — Wed, 13 May 2026 16:07:42 +0000

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.

Event Driven Architecture (EDA) with Kafka: Designing Events and Channels the Right Way

Tayfun Yalcinkaya — Wed, 13 May 2026 15:53:37 +0000

Enterprise organizations around the world are moving away from relying only on batch analytics that run hours or days after an event has happened. Instead, they are adopting architectures that can react when events occur. In areas such as fraud detection, real-time customer experience, IoT monitoring, payment systems, operational dashboards, and security analytics, Event Driven Architecture is no longer only a modern integration pattern. It has become one of the key building blocks of real-time data platforms.

The reason is simple: in many organizations, chronic batch analytics problems are not only technology problems; they are timing problems. Data is collected, moved, processed, and reported. But by the time the business receives the result, the decision may already be late. When EDA is designed correctly, it reduces this delay. It allows data to be processed as events happen, providing lower latency, faster action, and a more flexible integration model.

At this point, it is more accurate to position EDA not as a direct replacement for batch processing, but as a different architectural response that complements it. Large historical data processing, periodic reporting, financial closing, and heavy bulk transformations are still strong areas for batch processing. EDA creates the most value when data is continuously flowing, decisions must be made quickly, and systems are expected to react to events almost immediately.

However, poorly designed Event Driven Architecture can turn streaming flows and real-time analytics into a serious mess inside data management platforms. At the beginning, a decision like “let’s create Kafka topics and let systems write there” may look simple. A few months later, it may turn into uncontrolled topic growth, unclear event ownership, unreliable data distribution, consumer dependency problems, reprocessing issues, and data flows that are difficult to trace.

This blog series is built around two main questions: How should we design an event, and how should an event mature inside the platform? In this first article, we will focus on the event itself: the difference between events and commands, the Kafka topic/channel model, schema contracts, partition keys, producer-consumer relationships, and common design mistakes. In the second article, we will look at the event lifecycle inside the platform: the pipeline from raw to curated events, DLQ (Dead Letter Queue : It is the channel where failed or unprocessable events are sent) and alert topics, replay, monitoring, governance, and the relationship with the Medallion approach used in modern lakehouse architectures.

What Is Event Driven Architecture?

Event Driven Architecture is an architectural approach where systems communicate through events instead of direct and synchronous calls.

An event represents a meaningful business fact that has already happened in the system:

A customer was created.
A payment was completed.
A card transaction failed.
Stock level dropped below a critical threshold.
A sensor temperature exceeded the limit.
A user logged in to a mobile application.

The important point is this: an event is not a request. It is information about something that has already happened.

For example:

PaymentCompleted
CustomerCreated
OrderShipped
MachineTemperatureExceeded

These are events because they describe something that happened in the past.

On the other hand:

CreatePayment
UpdateCustomer
SendNotification

These are closer to commands. They express an intention to make a system do something. In EDA design, separating events from commands is a critical decision.

The Difference Between Traditional Integration and EDA

In traditional architectures, systems usually call each other directly.

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

This model looks simple at a small scale. However, as the number of systems increases, dependencies grow. If one service becomes slow, fails, or changes, the other systems in the chain may also be affected.

In EDA, systems do not directly depend on each other. Instead, they publish events, and the systems interested in those events consume them.

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

With this model, the producer system does not need to know who will consume the event. A new consumer can be added without changing the existing producer application.

Where Does Kafka Fit in EDA?

In EDA architectures, Kafka is usually positioned as an event backbone, event bus, or event streaming platform.

The core Kafka concepts are:

Producer: The application that produces events.
Topic: The logical channel where events are written.
Partition: The unit that enables parallel processing within a topic.
Consumer: The application that reads events.
Consumer Group: A group of consumers that share the same work.
Broker: A server inside the Kafka cluster.
Offset: The position that shows how far a consumer has read in a topic.
Retention: The policy that defines how long events stay in Kafka.

A simple Kafka-based EDA flow can be shown like this:

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

Here, Kafka topics act as event channels between systems.

What Does Channel-Based Kafka Design Mean?

A channel-based structure usually means separating event types or business domains through Kafka topics.

For example, for a payment system:

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

For a customer domain:

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

For an IoT or manufacturing scenario:

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

Each topic is an event channel. The producer application writes events to the related channel. Consumer applications read the channels they are interested in and perform their own work.

An Anonymized Field Example: Channel-Based Design for Energy Distribution Data

The following example is anonymized from a large-scale data platform project in the energy distribution domain. Without sharing the organization or project name, it aims to make the real architectural needs and EDA design decisions from the field more visible.

In this scenario, the main need was to centrally collect, securely transport, process, and analyze data coming from smart meters and lighting infrastructure across the country. At first glance, this may look like an integration project. However, when we consider the data volume, the number of source systems, the need for 24/7 operation, security expectations, and operational monitoring requirements, the problem becomes much bigger than classical integration. A real-time and always-on data flow architecture was needed.

One of the most critical decisions in the field was Kafka topic design. Different types of meter data were coming from multiple distribution companies: electricity consumption data, meter activity data, online/offline status information, and operational signals. Writing all data into one large topic could look simpler at first. But this would create serious complexity for consumers in terms of filtering, scaling, error handling, and monitoring.

For this reason, a source-based and data-type-based channel approach was preferred. Dozens of Kafka topics were designed based on distribution company and data type. This allowed each flow to be monitored separately, consumed separately, and scaled independently when needed.

This logic can be represented as follows:

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

In this design, Kafka was not only a messaging layer. It became the central event backbone that separated high-volume data from different sources into organized channels. As a result, real-time monitoring services, consumers writing to operational databases, archiving processes, and analytics platforms could all be fed independently from the same data flow.

The main lesson from this example is clear: in channel-based Kafka design, a growing number of topics is not a problem by itself. The real problem starts when it is not clear which domain, data type, ownership model, and consumption purpose each topic serves.

Event or Command?

One of the common mistakes in EDA design is mixing events and commands.

An event represents a business fact that has already happened:

PaymentCompleted
CustomerCreated
OrderShipped

A command represents an action that we want a system to perform:

CreatePayment
UpdateCustomer
SendNotification

Commands can also be carried over Kafka. However, this makes topics such as timeout, retry, correlation, response handling, and idempotency more complex. For this reason, in Kafka-based EDA design, it is usually healthier to start by modeling things that have already happened.

Business Event State and Data Pipeline Stage Should Not Be Mixed

Another important distinction in EDA design is the difference between business state and data processing stage.

A business event lifecycle may look like this:

PaymentInitiated -> PaymentAuthorized -> PaymentCompleted -> PaymentSettled

A data pipeline stage may look like this:

raw -> validated -> enriched -> curated

The first one describes the state changes of a business process. The second one describes the maturity of data inside the platform. Separating these two concepts is very important for correct topic design.

In the first article, we focus more on business events and channel design. In the second article, we will explain data pipeline stages such as raw, validated, enriched, and curated in more detail.

What to Consider in Topic Design

When designing EDA on Kafka, topic naming, partition strategy, and ownership are among the most critical decisions.

An example topic naming standard can be:

<domain>.<entity>.<event>

Examples:

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

Some organizations also prefer to include the stage information in the topic name:

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

The important point is not that there is only one correct naming standard. The important point is having a consistent standard across the organization.

A good topic name should answer these questions:

Which domain does it belong to?
Which entity or business object does it represent?
Which event does it carry?
Which team owns this topic?
Is this topic a stable contract, or is it a temporary processing topic?

Partition Key Selection

In Kafka, partition key selection affects both performance and ordering guarantees.

For example, if events related to the same customer must be processed in order, customer_id can be selected as the key.

Topic: payment.transaction
Key: customer_id

If transactions related to the same card must be processed in order, card_id may be a better choice.

Topic: card.transaction
Key: card_id

A poor key choice can overload some partitions while leaving others almost empty. This causes a hot partition problem.

When selecting a partition key, these questions should be asked:

What level of ordering do we need?
Which key provides a more balanced distribution?
How will consumer parallelism scale?
Should events related to the same business entity stay in the same partition?

Schema Management

In EDA, the event contract is very important. Even if producers and consumers do not know each other directly, they agree through the schema.

For this reason, each event type should have a clear schema management approach.

Key points to consider:

Event schemas should be versioned.
Backward compatibility rules should be defined.
Required and optional fields should be clear.
Metadata fields such as event timestamp, event_id, and source_system should be standardized.
If a breaking change is needed, a new version or a new topic strategy should be defined.

Example metadata fields:

{
  "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"
}

If schema management is ignored, Kafka topics slowly stop being reliable event contracts. Then the answer to “who writes what and who reads it how?” becomes unclear.

Producer and Consumer Relationship

One of the most important advantages of EDA is loose coupling between producers and consumers.

The producer application publishes the event. It does not need to know how many consumers will read it.

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

This model allows new use cases to be added without changing the existing producer application. However, this flexibility can quickly turn into uncontrolled consumer dependency if topic ownership and schema contracts are not clear.

For every critical topic, the following information should be clear:

Who owns the topic?
Which application is the producer?
Which schema versions are supported?
Who is allowed to consume it?
What is the retention policy?
How are breaking changes managed?

Common EDA Design Mistakes

EDA projects usually fail not because Kafka is weak, but because architectural decisions are not clear enough.

Common mistakes include:

Creating topics for every need without control.
Mixing events and commands.
Not defining topic ownership.
Ignoring schema management.
Choosing partition keys randomly.
Defining retention without business requirements.
Not documenting producer and consumer contracts.
Mixing business event state with data pipeline stages.
Thinking about monitoring, security, and governance too late.

Conclusion

Event Driven Architecture is a powerful approach for real-time data flows and analytics needs. However, the success of EDA does not start with installing a Kafka cluster. It starts with designing the right event model.

A good EDA design should clearly answer these questions:

Which events will be produced?
How will we separate events from commands?
What will the topic/channel standard be?
Who will own each topic?
How will schemas be managed?
How will partition keys be selected?
How will producer and consumer contracts be protected?

In this article, we covered event modeling, Kafka topic/channel design, schema contracts, and producer-consumer relationships. In the next article, we will look at how these events mature inside the platform: raw, validated, enriched, and curated flows, DLQ and alert topics, replay strategy, monitoring, and the relationship with the Medallion approach used in modern lakehouse architectures.

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

Why Apache Ozone is the Preferred Object Store for Big Data

Tayfun Yalcinkaya — Mon, 05 Jan 2026 21:42:00 +0000

The limitations of traditional HDFS architecture when facing billions of small files, combined with the search for S3-like flexibility in on-premise environments, drive us toward a modern solution: Apache Ozone.

From a technology perspective, the abundance of products and methods available for data storage requires serious expertise to navigate. If you need to store a wide variety of data, standard RDBMS technologies will eventually fall short. You need to turn to independent, cost-effective, yet efficient storage technologies that allow you to query data performantly regardless of its type.

The Shift to On-Premise Object Storage

If your data landscape includes structured, semi-structured, and unstructured data, and you aim for cost efficiency by avoiding separate silos, all paths lead to an object storage architecture, implemented through an on-premise object store. For organizations with requirements to keep data in-house, on-premise solutions are a necessity.

Unlike traditional object storage systems that prioritize API compatibility, Apache Ozone is designed as a storage system optimized for analytical engines rather than object semantics alone.

While the market offers several options like MinIO or Ceph , if you are utilizing big data engines such as Hive, Spark, Trino, or Impala, there is a particularly optimized solution: Apache Ozone.

(You can explore the technical architecture of Apache Ozone here).

Key Technical Advantages of Apache Ozone

Source: Cloudera Ozone Overview Documentation

Strong Consistency:
Ozone is designed to provide strong consistency via the Raft consensus protocol. This ensures that data is immediately visible once written, with guaranteed atomic write support. In contrast, S3-compatible interfaces in other systems may exhibit eventual consistency, leading to potential delays or conflicts during overwrite or list operations.
Native Ecosystem Integration:
Unlike basic S3-compatible stores that offer limited integration with tools like Hive and Impala, Ozone is built as a core part of the Hadoop ecosystem. This results in seamless, out-of-the-box support for major big data processing engines Hive, Spark, and Trino.For instance, you can check the detailed Hive Integration Documentation to see the level of optimization.
POSIX Compatibility & File System Behavior:
Through its OFS layer, Ozone offers POSIX-like behavior and a directory hierarchy. This allows for native atomic renames, which are crucial for the performance and reliability of Hadoop-based workloads.
Full Kerberos Support:
Leveraging its native Hadoop compatibility, Ozone offers full integration with Kerberos for enterprise-grade security , a feature often lacking in S3-only object stores.

Feature	Apache Ozone	S3 (MinIO, Ceph, etc.)
Performance	Optimized for large-scale data lakes	High throughput, limited metadata handling
Consistency Model	Strong Consistency (Raft-based)	Eventual Consistency (possible delays)
Hadoop/Spark/Trino	Native & Seamless Integration	Limited (especially for Hive/Impala)
POSIX / File System	POSIX-like (Native Atomic Rename)	None (Object-based only)
Kerberos Support	Fully Compatible (Native)	None

The Perfect Match for Modern Data Lakehouse (Apache Iceberg)
If you are moving toward a Data Lakehouse architecture using Apache Iceberg, Ozone stands out as the superior storage layer:

Atomic Commits:
Iceberg relies on atomic metadata updates to prevent data corruption during concurrent writes. Ozone supports this natively through its atomic rename functionality.
Native Locking:
It supports the locking mechanisms necessary to prevent metadata inconsistencies , whereas S3-compatible stores often require external services like Zookeeper to manage locks.
Snapshot Isolation:
Ozone’s architecture ensures that data is not considered committed until acknowledged by all replicas, preserving the consistent view that Iceberg’s immutable file model requires.

Feature	Apache Ozone	S3-compatible Object Stores
Atomic Commits	Fully Supported (via OFS)	No native support (workarounds required)
Locking Mechanism	Native Support	Requires external tools (Zookeeper, etc.)
Snapshot Isolation	Guaranteed (Strong Consistency)	Very limited / Eventual consistency
Directory Structure	Native Support	Simulated (Prefix-based)

Conclusion
For organizations aiming to process unstructured and structured data effectively using Spark, Hive, or Trino. Apache Ozone is not just an alternative. It is a purpose-built on-premise object store for big data workloads. It bridges the gap between traditional file systems and modern object storage, making it the ideal choice for high-performance data lakehouse architectures.

What is your preferred storage layer for on-premise big data projects? How could Ozone’s advantages resolve bottlenecks in your current architecture?

Written by Tayfun Yalçınkaya, working on large-scale Big Data platforms and Lakehouse architectures.
Connect with me on LinkedIn