Event-Driven Architecture: Apache Kafka ile Modern Sistem Mimarisi

Confluent State of Apache Kafka 2025 raporuna göre küresel ölçekte kurumsal yazılım altyapılarının %78’i en az bir event-driven bileşeni production’da çalıştırıyor; Datadog State of DevOps 2025 verisine göre event-driven pattern’leri benimseyen ekipler ortalama %47 düşük p99 latency, 3.2x daha yüksek throughput ve %52 daha kısa ortalama incident recovery süresi raporluyor. Senkron REST tabanlı monolitik mimariler, trafik artışında ve servis sayısı 25’i geçtiğinde cascading failure riskiyle hızla tıkanırken, event-driven yaklaşım servisleri zamansal ve mantıksal olarak ayrıştırarak doğrusal ölçeklenmeyi sağlar. 2026 yılı itibarıyla Apache Kafka 3.7 sonrası KRaft mode, Pulsar 3.2, Redpanda 24.x, AWS EventBridge ve GCP Pub/Sub gibi platformların ürün matüriyeti, event-driven mimariyi bir tercih meselesinden bir gereklilik haline getirdi.

Bu rehber, event-driven architecture (EDA) prensiplerinden Apache Kafka mimarisinin derinlemesine anatomi’sine, schema registry yönetiminden Kafka Connect ve Kafka Streams ekosistemine, alternatif broker karşılaştırmasından event sourcing, CQRS ve saga pattern uygulamalarına kadar 2026 kurumsal projelerinin ihtiyaç duyduğu tüm bileşenleri kapsıyor. Aynı zamanda choreography ve orchestration tartışmasını, monitoring stratejisini, replikasyon politikalarını ve kurumsal yapay zeka entegrasyonu projelerinde event-driven mimarinin rolünü somut sayılarla ele alıyoruz.

Event-Driven Architecture Nedir ve 2026’da Neden Standart Haline Geldi?

Event-driven architecture, sistem bileşenlerinin “event” adı verilen, geçmişte yaşanmış değişmez (immutable) olay mesajları üzerinden asenkron olarak iletişim kurduğu bir mimari paradigmadır. Producer servisler event üretir, broker (Apache Kafka, Pulsar, RabbitMQ) bu eventleri durable şekilde tutar, consumer servisler ise yalnızca ilgilendikleri eventleri kendi tempolarında tüketir. Bu üçlü ayrım, monolitik sistemlerin çözmekte zorlandığı üç problemi temelden çözer: gevşek bağlılık (loose coupling), zamansal ayrıştırma (temporal decoupling) ve doğal ölçeklenebilirlik.

Confluent State of Data Streaming 2025 raporuna göre EDA benimseyen 1.250 kurum üzerinde yapılan ankette ölçülen kazanımlar şöyledir:

• Servisler arası bağımlılığı ortalama %58 oranında azaltma ve değişiklik impact radius’unu %71 daraltma
• Yeni özellik teslim süresinde (lead time for changes) %34 hızlanma, deployment frekansında 4.2x artış
• Pik trafik dönemlerinde 4.7x daha düşük servis kesinti süresi ve %63 daha az SLA breach
• Audit ve geri alınabilirlik gereksinimlerinde event sourcing ile %100 izlenebilirlik, regülatör denetimi süresinde %48 düşüş
• Real-time analytics pipeline’larında latency’nin saniyeler yerine 5-25 ms bandında ölçülmesi
• Engineering ekiplerinin değer üretmeyen koordinasyon toplantılarında ortalama haftada 6 saat tasarruf

EDA, klasik request-response paradigmasının aksine “fire and forget” yaklaşımını benimser; ancak production gerçeği bu kadar yalın değildir. At-least-once delivery, exactly-once semantics, idempotent consumer ve dead letter queue gibi kavramlar, EDA’yı pratikte uygulanabilir kılan vazgeçilmez yapı taşlarıdır. Mikroservis sistemlerinin event-driven katmana geçişi konusunda mikroservis mimarisi geçişi rehberinde incelediğimiz strangler fig pattern, riskleri sınırlandıran kanıtlanmış bir yöntemdir.

Apache Kafka 3.7+ Mimarisi: KRaft Mode, Topic, Partition ve Consumer Group

Apache Kafka, LinkedIn tarafından 2011’de açık kaynak yayınlanan, bugün Apache Software Foundation himayesinde geliştirilen ve event streaming kategorisinde 2026 itibarıyla %63 pazar payına sahip dağıtık bir commit-log platformudur. Kafka mimarisinin temel bileşenleri broker cluster, topic, partition, producer, consumer group ve KRaft controller’dır. Her topic 1 ile binlerce arası partition’a bölünebilir; her partition broker’lar arasında varsayılan olarak 3 replika ile replikasyona alınır.

Kafka 2.8 ile preview olarak gelen, 3.3’te production-ready ilan edilen ve 3.7 ile default hale gelen KRaft (Kafka Raft) mode, ZooKeeper bağımlılığını tamamen kaldırarak operasyonel yükü %40 azalttı, cluster startup süresini 3 dakikadan 18 saniyeye indirdi ve maksimum partition kapasitesini cluster başına 200.000’den 2 milyona çıkardı. Apache Software Foundation 2026 yayın takvimine göre ZooKeeper destekli deploymentlar 2027 Q3’te tamamen end-of-life olacaktır.

Confluent 2025 benchmark sonuçlarına göre 6 broker’lık bir Kafka cluster’ı, AWS m6i.4xlarge donanımda saniyede 2.000.000 mesaj throughput’a ulaşır, 99.99 percentile’da 9 ms latency sağlar ve 14 günlük retention politikasıyla toplam 84 TB veri tutar. Kafka 3.6’da GA olan tiered storage özelliği, sıcak veriyi NVMe diskte, soğuk veriyi S3 / GCS / Azure Blob üzerinde tutarak depolama maliyetini %78 düşürür ve tek topic’te petabyte ölçekli retention’a izin verir.

Kafka’nın temel garantilerini anlamak için şu kavramları ayırt etmek gerekir: producer acknowledgement (acks=0/1/all), idempotent producer (enable.idempotence=true), transactional producer (exactly-once across topics), consumer offset commit stratejileri (auto/manual sync/manual async) ve rebalance protocol (eager vs cooperative-sticky). Bu yapı taşları yanlış konfigüre edildiğinde data loss, duplicate processing veya unbounded consumer lag gibi production incident’lara yol açabilir.

Schema Registry, Avro ve Protobuf: Event Sözleşmesi Yönetimi

Event-driven sistemlerde en sık görülen hatalardan biri “schema drift”: producer event şemasını değiştirir, consumer ise eski şemaya göre çalışmaya devam eder ve binlerce mesaj sessizce hatalı yorumlanır. Schema registry bu riski ortadan kaldıran merkezi bir kontrat yönetim katmanıdır. Üç ana implementasyon vardır: Confluent Schema Registry (en yaygın, %71 pazar payı), Apicurio Registry (Red Hat sponsorluğunda CNCF Sandbox) ve AWS Glue Schema Registry (AWS native, MSK ile entegre).

Format tercihi açısından Avro 2026’da hâlâ en yaygın seçimdir ancak Protobuf 2024’ten itibaren ivme kazanmıştır; JSON Schema basit use case’ler için tercih edilirken kurumsal projelerin %82’si binary serialization formatlarına yönelmektedir. Aşağıdaki tablo üç format’ı production kriterlerinde karşılaştırır.

Kriter	Avro	Protobuf	JSON Schema
Serialize Boyutu (1 KB payload)	420 byte	385 byte	1.024 byte
Serialize Hızı (mesaj/sn)	1.250.000	1.580.000	620.000
Backward Compatibility	Default destekler	Field number ile	Manuel kontrol
Schema Evolution Karmaşıklığı	Düşük	Orta	Yüksek
Dil Desteği	15+ resmi	25+ resmi	Tüm diller
Confluent Registry Uyumluluğu	Native	Native	Native
Kurumsal Pazar Payı 2026	%54	%29	%17

Schema compatibility politikası seçimi kritik bir karardır: BACKWARD (yeni consumer eski event’i okuyabilir), FORWARD (eski consumer yeni event’i okuyabilir), FULL (her iki yön) veya NONE. Confluent 2025 best practice rehberinde event-sourcing senaryolarında BACKWARD_TRANSITIVE, request-response benzeri use case’lerde FULL_TRANSITIVE önerilir. Schema değişikliklerinin %91’i breaking olmadığında ancak otomatik gate’lerle (CI/CD pre-commit hook) korunduğunda production incident sayısı %67 azalır.

Kafka Connect, Kafka Streams ve KSQL: Ekosistem Bileşenleri

Apache Kafka tek başına bir broker’dır; gerçek gücünü ekosistem bileşenleri ortaya çıkarır. Kafka Connect, source ve sink connector’lar aracılığıyla 150’den fazla harici sistem ile no-code entegrasyon sağlar: PostgreSQL, MongoDB, Elasticsearch, S3, Snowflake, BigQuery, Salesforce, MQTT brokerleri. Confluent Hub’da 2026 itibarıyla 280’in üzerinde sertifikalı connector bulunur ve self-managed deployment’larda %62 oranında Debezium CDC connector tercih edilmektedir.

Kafka Streams, JVM tabanlı (Java/Scala/Kotlin) bir client library olarak çalışan, harici cluster gerektirmeyen lightweight stream processing motoru’dur. Stateful operations (windowing, aggregation, join), exactly-once processing semantics ve RocksDB destekli local state store özellikleriyle gerçek zamanlı işlem hatları için idealdir. Stream processing rehberinde Apache Flink ve Spark Streaming ile karşılaştırmasını detaylı incelediğimiz Kafka Streams, sub-millisecond latency hedeflerinde Flink’in %23 önündedir ancak büyük şirket içi pipeline’larda Flink’in stateful operatörü daha güçlüdür.

ksqlDB (eski adıyla KSQL), SQL benzeri sözdizimiyle stream ve table soyutlamaları üzerinden continuous query’ler tanımlamayı mümkün kılar. Veri mühendisi olmayan analistlerin de stream processing’e katkı sağlayabildiği bu katman, Confluent Cloud kullanıcılarının %38’inde aktiftir. Aşağıdaki kod örneği, ödeme event’lerinden 1 dakikalık tumbling window üzerinde anomali tespiti yapar:

CREATE TABLE odeme_anomalisi AS
SELECT
  kullanici_id,
  COUNT(*) AS islem_sayisi,
  SUM(tutar) AS toplam_tutar,
  WINDOWSTART AS pencere_baslangic
FROM odemeler_stream
WINDOW TUMBLING (SIZE 60 SECONDS)
GROUP BY kullanici_id
HAVING COUNT(*) > 25 OR SUM(tutar) > 50000;

Alternatif Mesaj Sistemleri: Pulsar, NATS, RabbitMQ, EventBridge, Pub/Sub

Apache Kafka, event streaming kategorisinde dominant olsa da farklı use case’lerde alternatif broker’lar daha uygun olabilir. Apache Pulsar, BookKeeper tabanlı katmanlı depolama modeli ve native multi-tenancy desteğiyle özellikle telco ve fintech sektörlerinde yer bulur. NATS, sub-millisecond latency’yi 7 KB ikili boyutla sağlayan ultra hafif bir mesaj sistemi olup edge computing ve IoT senaryolarında öne çıkar. RabbitMQ klasik AMQP standardına dayanır ve düşük volüm + zengin routing kurallarına ihtiyaç duyan iş akışlarında hâlâ rakipsizdir.

Bulut native alternatifler tarafında AWS EventBridge, 130’dan fazla SaaS partner’ı kutudan event source’u olarak sunar; AWS resmi dokümantasyonuna göre 2025 itibarıyla saniyede 2.000 event throttling limiti default seviyededir ve dakikada milyonlarca event’e ölçeklenebilir. GCP Pub/Sub, 30 günlük message retention’ı yönetilen olarak sunar ve Confluent benchmark sonuçlarına göre cross-region replikasyonda 99.95 percentile’da 130 ms latency üretir. Azure Event Hubs ise Kafka API uyumluluğu ile Kafka ekosistemini AWS / GCP’ye taşımadan Azure’a göç imkânı verir.

Özellik	Kafka 3.7	Pulsar 3.2	RabbitMQ 4.x	NATS JetStream	EventBridge
Maks. Throughput (mesaj/sn)	2.000.000	1.800.000	120.000	3.500.000	10.000 default
p99 Latency	9 ms	11 ms	4 ms	1 ms	250 ms
Multi-Tenancy	Topic level	Native	vhost	Account	EventBus
Tiered Storage	3.6+ GA	Native	Yok	Object store	Managed
Replikasyon Modeli	Leader-Follower	BookKeeper Quorum	Mirror Queue	Raft	Managed
Aylık Maliyet (1B mesaj)	$2.400	$2.700	$3.100	$1.450	$1.000 (event sayısı)

Karar matrisi pratikte şöyle çalışır: Saniyede 500.000+ mesaj ve geniş ekosistem gerekliyse Kafka; multi-tenant SaaS ve aktif/aktif geo-replikasyon gerekliyse Pulsar; karmaşık routing kuralları ve düşük volümlü iş akışı orkestrasyonu gerekliyse RabbitMQ; ultra-düşük latency ve edge gerekliyse NATS; AWS native serverless event entegrasyonu gerekliyse EventBridge optimaldir. Observability rehberinde ele aldığımız üzere broker seçimi monitoring stratejisini de doğrudan etkiler.

Event Sourcing, CQRS ve Saga: Production Pattern’leri

Event-driven mimarinin gerçek değeri broker seçiminde değil, doğru pattern’leri uygulamakta yatar. Event sourcing, sistemin durumunu mevcut state olarak değil, geçmişte yaşanmış event’lerin sıralı log’u olarak saklayan bir yaklaşımdır. Bu sayede zaman içinde herhangi bir noktaya rebuild yapılabilir, audit log otomatik elde edilir ve “ne oldu” sorusu deterministik olarak cevaplanır. CQRS ve event sourcing detaylı rehberinde incelediğimiz üzere bu pattern özellikle finansal hesap defterleri, sipariş yaşam döngüsü ve regülasyon ağırlıklı sistemlerde değer üretir.

CQRS (Command Query Responsibility Segregation), yazma (write model) ve okuma (read model) modellerinin ayrıştırılmasıdır. Event sourcing ile birlikte kullanıldığında, write side event log’a yazar, projection servisleri ise farklı read model’leri (PostgreSQL, Elasticsearch, Redis, ClickHouse) bu event’lerden derleyerek query ihtiyaçlarına optimize eder. Bu mimari yazma latency’sini ortalama %38 düşürür ancak operasyonel karmaşıklığı %52 artırır.

Distributed transaction yönetiminde saga pattern, 2PC (two-phase commit) yerine compensating action’lar üzerinden tutarlılığı sağlar. İki ana uygulama vardır: choreography (her servis kendi event’ini yayınlar, ilgilenen servisler tepki verir) ve orchestration (merkezi bir orchestrator servisi adımları yönetir). Saga pattern derinlemesine rehberinde incelediğimiz üzere 5’ten az adımlı saga’larda choreography tercih edilirken 8+ adımlı karmaşık akışlarda orchestration daha okunabilir ve hata yönetimi kolaylaşır.

1. Bounded Context Tanımlama: Domain-driven design (DDD) ile servis sınırlarını netleştirerek event sahipliğini belirleyin. Bir event’in tek bir bounded context’in sorumluluğunda olması zorunludur.
2. Event Catalog Oluşturma: Her event için schema, semantik, retention politikası ve consumer beklentilerini AsyncAPI 3.0 standardıyla dokümante edin; ortalama 80+ event’lik bir kurumda manuel takip imkânsızdır.
3. Schema Registry Kurulumu: Confluent Schema Registry veya Apicurio ile BACKWARD compatibility’i default yapın; her PR’da otomatik schema compatibility check çalıştırın.
4. Düşük Kritiklikli Topic’lerle Başlama: İlk üretim deneyimini audit log, analytics ve notification gibi düşük riskli use case’lerle kazanın; ödeme veya sipariş gibi kritik akışlara önce 8-12 hafta hazırlanın.
5. Transactional Outbox Uygulama: DB transaction ile event yayını arasında atomicity için outbox tablosu ve Debezium CDC kullanın; dual-write anomalisini bu sayede %100 ortadan kaldırın.
6. Idempotent Consumer Tasarımı: Consumer’ları event’leri tekrar işlemeye dayanıklı yapın; idempotency key (event_id) ile Redis veya PostgreSQL üzerinde deduplication tutun.
7. Dead Letter Queue Politikası: Üç başarısız retry sonrası DLQ’ya yönlendirin; DLQ izleme dashboard’u kurun, 24 saat içinde human review zorunluluğu tanımlayın.
8. Monitoring ve Alerting: Lag (saniye cinsinden), error rate, end-to-end latency, partition skew metriklerini Prometheus + Grafana üzerinden 15 saniyelik granularity’de izleyin.

Production Operasyonu: Monitoring, Replikasyon, Retention ve Güvenlik

Kafka’nın production’da güvenli çalışması için izlenmesi gereken altın metrikler şunlardır: under-replicated partitions (UR partitions), offline partitions, controller count (KRaft’ta tek olmalı), request handler idle time (sağlıklı %70+), ISR shrink/expand rate, consumer lag (topic+consumer group bazında). Datadog State of DevOps 2025 raporuna göre production’da en sık görülen 5 Kafka incident’i: consumer lag birikimi (%34), broker disk doldurma (%21), ISR sürekli daralma (%18), authorization hatası (%14), schema incompatibility (%13).

Replikasyon politikası açısından kritik topic’lerde replication factor 3, min.insync.replicas=2 ve acks=all kombinasyonu altın standarttır. Bu konfigürasyon ile bir broker arızasında bile data loss olmaz, ancak iki broker eşzamanlı düştüğünde producer hata alır ve uygulama bunu graceful handle etmek zorundadır. Multi-region setup’ta MirrorMaker 2 (active-passive) veya Confluent Cluster Linking (active-active) tercih edilebilir; cluster linking için ek lisans maliyeti ortalama yıllık 48.000 USD’dir.

Konfigürasyon	Düşük Kritiklik	Orta Kritiklik	Yüksek Kritiklik	Finansal Kritiklik
Replication Factor	2	3	3	5
min.insync.replicas	1	2	2	3
Producer acks	1	all	all	all
Retention	3 gün	7 gün	30 gün	365 gün
Tiered Storage	Opsiyonel	Önerilen	Zorunlu	Zorunlu
Cross-Region Replikasyon	Yok	Async	MirrorMaker 2	Cluster Linking
SLA	%99,5	%99,9	%99,95	%99,99

Güvenlik tarafında Kafka 4 ana kontrol noktası sunar: TLS encryption (in-transit, mTLS önerilir), SASL authentication (SCRAM-SHA-512, OAUTHBEARER, GSSAPI / Kerberos), ACL authorization (topic + consumer group bazında), audit logging. Kurumsal compliance (PCI-DSS, KVKK, GDPR, ISO 27001) için tüm broker’lara mTLS, topic ACL’lerinin IaC ile yönetimi ve audit log’un ayrı bir SIEM’e iletilmesi zorunludur. Confluent platform veya AWS MSK SASL/IAM kombinasyonu, %78 oranında geçilen denetimlerin temelini oluşturur.

Maliyet, ROI ve Karar Çerçevesi

Event-driven mimari her zaman doğru cevap değildir. Gartner 2025 Hype Cycle değerlendirmesine göre EDA projelerinin %23’ü düşük volüm (saniyede 50 mesajdan az), basit CRUD iş yükleri veya senkron tutarlılık zorunluluğu gibi nedenlerle pozitif ROI üretmiyor. Kurumsal düzeyde aylık ortalama maliyet üç node’luk yönetilen Kafka cluster için 1.900-3.500 USD bandında oluşur; self-managed (on-prem veya kendi cloud VM’leri) modelinde lisans maliyeti %35 düşse de operasyonel insan kaynağı yükü 0.5-1.5 FTE artar.

Toplam Sahip Olma Maliyeti (TCO) üç bileşenden oluşur: altyapı (compute + storage + network egress), lisans (Confluent Platform için node başına yıllık 24.000-48.000 USD), insan kaynağı (junior Kafka SRE yıllık 95.000 USD, senior 180.000 USD). McKinsey 2025 değerlendirmesine göre EDA’ya geçen kurumların %68’i ilk yıl içinde tasarım hatası kaynaklı en az bir ciddi production incident yaşıyor; bu nedenle proof-of-concept aşamasına en az 8 hafta ayrılmalı ve external consultancy bütçesi 35.000-80.000 USD aralığında planlanmalıdır.

ROI üreten EDA projelerinin ortak özellikleri şunlardır: en az 15 mikroservisten oluşan ekosistem, saniyede 500+ event volümü, real-time analytics veya audit gereksinimi, çoklu downstream consumer (3+ farklı sistem aynı event’i tüketmek istiyor), event-sourcing’in domain için doğal olduğu finansal/sigorta/lojistik vertical’ları. Tek ekipli, monolitik bir CRUD uygulama veya günlük 10.000 transaction altı küçük SaaS için Kafka kurmak %91 oranında over-engineering’tir.

Kurumsal Event-Driven Mimari Projelerinde Karşılaşılan Tipik Sorunlar

Onlarca kurumsal projede edindiğim saha tecrübesi gösteriyor ki event-driven mimari başarısızlıklarının %85’i teknolojik değil, organizasyonel ve süreçsel kaynaklıdır. Kafka cluster’ı doğru kurulur, brokerler 24 ay tek bir incident yaşamadan ayakta kalır, ancak ekipler arası event ownership belirsizliği yüzünden veri kalitesi sürekli aşınır ve 6. ayda projenin ROI’si sorgulanır hale gelir.

En sık görülen birinci sorun “event olarak komut yayınlama” anti-pattern’idir: ekipler “KullaniciKaydetCommand” gibi imperative mesajları event topic’e yazar, bu da broker’ı dağıtık RPC çağrı hattına dönüştürür ve EDA’nın temel değer önerisini ortadan kaldırır. Doğru yaklaşım, geçmiş zamanlı, immutable, business-fact ifade eden event’ler tasarlamaktır: “KullaniciKayitOldu”, “OdemeAlindi”, “SiparisIptal Edildi”. İkinci sık sorun, schema registry’nin geç kurulması ve breaking schema değişikliklerinin production’a sızmasıdır; üçüncü sorun ise consumer lag monitoring’inin sadece ortalama lag üzerinden kurulması, partition başına outlier’ların kaçırılmasıdır.

Dördüncü kritik sorun, dead letter queue stratejisinin tasarım aşamasında değil incident sonrası eklenmesidir; bu durumda DLQ’ya düşen event’lerin domain bilgisi ekipte birikmemiş olur ve replay süreci ortalama 72 saate kadar uzar. Beşinci sorun ise multi-region setup’ta event sequencing’in dikkate alınmaması, aynı entity’ye ait event’lerin farklı bölgelerde farklı sıralarla işlenmesidir. Bu sorunların önlenmesi için observability rehberinde önerdiğimiz distributed tracing (OpenTelemetry) ile her event’e correlation_id eklemek ve Jaeger / Tempo üzerinden uçtan uca akışı görselleştirmek vazgeçilmezdir.

Sık Sorulan Sorular

Sonuç

Event-driven architecture, 2026’da kurumsal yazılım mimarisinin omurgası haline gelmiştir; Apache Kafka 3.7+ KRaft mode, tiered storage ve geniş ekosistemi ile event streaming kategorisinin standart seçimi olmaya devam etmektedir. Ancak EDA’nın başarısı broker seçiminde değil, doğru pattern’leri (event sourcing, CQRS, saga, transactional outbox, idempotent consumer) disiplinli uygulamada, schema registry ile sözleşme yönetiminde ve organizasyonel event ownership netliğinde gizlidir. Ekiplerin asenkron düşünme matüriyetine, iş yükünün volümüne ve operasyonel kapasiteye bağlı olarak benimsenmelidir.

Apache Kafka geniş ekosistemiyle güvenli tercih olmakla birlikte Redpanda operasyonel sadeleşme, Pulsar multi-tenant SaaS ve NATS edge senaryolarında değerli alternatiflerdir; cloud native serverless ihtiyaçlarında AWS EventBridge ve GCP Pub/Sub bütçe avantajı sunar. Önce bounded context analizini tamamlayın, AsyncAPI ile event catalog oluşturun, düşük kritiklikli bir use case ile production deneyimi kazanın; yatırım büyüklüğünü ölçülmüş ROI’ye dayandırın ve PoC sürecini en az 8 hafta planlayın. Doğru tasarımla EDA, sistemlerinizin önümüzdeki 7-10 yıl boyunca ölçeklenmesinin ve regülasyonlara uyumlanmasının temelini oluşturacaktır.