1. GİRİŞ

Olay tabanlı mimari (Event Driven Architecture — EDA) modern dağıtık sistemlerin, mikroservis ekosistemlerinin ve gerçek zamanlı veri işleme platformlarının temel yaklaşımlarından biri haline gelmiştir. Dijitalleşme hızı, kullanıcı beklentilerinin gerçek zamanlı geri bildirim gerektirmesi ve veri hacimlerinin artması, sistemlerin reaktif, gevşek bağlı ve ölçeklenebilir olmasını zorunlu kılar. EDA, komponentlerin birbirleriyle olaylar (events) üzerinden iletişim kurduğu; dolayısıyla düşük bağlılık, yüksek ölçeklenebilirlik ve esneklik sağlayan bir model sunar.

Bu konu neden konuşuluyor?

• Gerçek zamanlı analitik, kullanıcı deneyimi ve düşük gecikme gereksinimleri artıyor.
• Mikroservis adoption ile servisler arası coupling azaltma ihtiyacı önem kazandı.
• Event sourcing, CQRS ve stream processing gibi desenlerin olgunlaşması uygulama tasarımlarını etkiliyor.

Kimler için önemli?

• Yazılım mimarları ve teknik liderler
• Platform mühendisleri, SRE ve DevOps ekipleri
• Backend geliştiriciler, veri mühendisleri ve MLOps ekipleri

Hangi problemleri çözüyor?

• Loose coupling: Servisler birbirlerini doğrudan çağırmak zorunda kalmadan çalışabilir.
• Scale-out: Yük, event stream'leri üzerinden yatay ölçeklenebilir şekilde karşılanır.
• Audit ve replay: Event sourcing ile geçmiş durumlar yeniden oluşturulabilir.
• Asenkron iş akışları: Uzun süreli işlemler saga veya workflow motorları ile yönetilir.

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

Event (Olay)

Sistemde meydana gelen anlamlı değişiklik veya durum bildirimi. Örnek: "OrderPlaced", "PaymentSucceeded".

Producer (Üretici)

Event üreten taraf — genelde bir servis veya uygulama parçası.

Consumer (Tüketici)

Event'i alan ve işleyen taraf — veri depolama, iş akışı tetikleme veya diğer servisler olabilir.

Event Bus / Message Broker

Event'lerin publish/subscribe mekanizmasıyla taşındığı altyapı (Kafka, Pulsar, RabbitMQ vb.).

Event Store

Event sourcing uygulamalarında olayların saklandığı dayanıklı log; aynı zamanda sistemin tek kaynağı (source of truth) olabilir.

2.2 Temel bileşenler

• Event producer ve consumer'lar
• Message broker veya streaming platformu
• Event schema registry / contract yönetimi
• Processing layer: stream processors, consumers, materialized views
• Monitoring, observability ve alerting

2.3 Terminoloji

• At‑least‑once, At‑most‑once, Exactly‑once teslim garantileri
• Idempotency: Tekrar eden event işleme durumunda yan etkiyi engelleme
• Schema evolution: Event format değişikliklerinin geriye dönük uyumlu yönetimi

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE İŞLEYİŞ

3.1 Sistem mimarisi genel bakış

EDA'da uygulama komponentleri olay üretir ve bu olaylar ortalama bir event bus aracılığıyla yayınlanır. Tüketiciler, ilgi duydukları event'lere abone olur ve asenkron olarak bu olayları işler. İşlem süreci genelde birkaç ana akış içerir: event üretimi, event publish, event storage (opsiyonel), stream processing ve tüketici tarafında yan etkilerin gerçekleştirilmesi.

3.2 Veri akışı

1. Uygulama bir durum değişikliği gerçekleştirir (örn. sipariş oluşturma).
2. Bu değişiklik bir event olarak serileştirilir ve bir broker'a publish edilir.
3. Broker bu event'i ilgili topic/stream'e yazar ve tüketiciler bu stream'i okur.
4. Tüketiciler event'i işleyip kendi yan etkilerini gerçekleştirir: veri güncelleme, dış sistem çağrısı, başka event publish etme vb.

3.3 Event modelleme ve schema yönetimi

Event'lerin doğru modellenmesi kritik önemdedir. Event schema'ları (Avro, Protobuf, JSON Schema) bir registry'de saklanmalı ve versiyonlanmalıdır. Schema evolution kuralları tüketicilerin bozulmadan çalışmasını sağlar: backward/forward compatibility prensipleri uygulanmalıdır.

3.4 Delivery ve processing garantileri

Mesajlaşma sistemleri farklı teslim ve işleme garantileri sunar. At‑least‑once, yüksek kullanılabilirlik için tipik tercih; ancak idempotency uygulamak gerekir. Exactly‑once semantiği genelde pahalıdır ve sadece özel platform özellikleri ile mümkün olabilir (ör. Kafka Streams, transactional messaging).

3.5 Event sourcing ve CQRS

Event sourcing, sistem durumunu doğrudan event set'inden yeniden oluşturma yaklaşımıdır. CQRS (Command Query Responsibility Segregation) ise okuma ve yazma path'lerini ayırarak performans ve model karmaşasını hafifletir. Bu iki desen birlikte güçlü audit, replay ve history analiz yetenekleri sağlar fakat maliyetleri ve karmaşıklığı artırır.

3.6 Saga ve iş akışı koordinasyonu

Saga pattern, bir işlem birden fazla servisi etkilediğinde distributed transaction yerine adım adım yürütülmeyi ve başarısızlık durumunda compensating action'lar tetiklemeyi sağlar. Saga'lar choreographed (her servis kendi adımını yönetir) veya orchestrated (merkezi bir orchestrator vardır) şekilde uygulanabilir.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix ve stream processing

Netflix, yüksek throughput gerektiren telemetri ve olay akışlarını işlemek için event driven yaklaşımlar kullanır. Stream processing ile anlık metrikler, uyarılar ve kullanıcı kişiselleştirme sağlanır.

Uber — Gerçek zamanlı routing ve event akışı

Uber'de konum, talep ve teklif akışları event bazlıdır. Anlık olaylar üzerinden karar verme, pricing ve dispatch sistemleri çalışır.

Amazon — Event driven e‑commerce

Amazon'da sipariş, stok ve faturalama gibi işlemler event chain'ler ile birbirine bağlanır. Event sourcing benzeri pattern'ler operasyonel güvenilirlik sağlar.

OpenAI & MLOps — Model pipeline'ları

MLOps süreçlerinde veri hazırlama, model eğitim tetikleme ve model dağıtımı event driven süreçlerle orkestre edilir. Bu sayede pipeline'lar otomatik, yeniden üretilebilir ve izlenebilir olur.

Fintech — Stripe örneği

Finansal işlemler, ödeme onayları, reconciliations event'ler üzerinden akıtılarak auditability ve hata toleransı artırılır. Saga desenleri ödeme süreçlerinde sıkça kullanılır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Loose coupling: Üretici ve tüketici birbirinden bağımsız evrimleşir.
• Ölçeklenebilirlik: Event stream'leri yatay olarak tüketici sayısıyla ölçeklenebilir.
• Audit & Replay: Olayların loglanması ile geçmiş durumların yeniden oluşturulması mümkün.
• Reactivity: Kullanıcı deneyimi ve real‑time analitik için uygun yapı sağlar.

Sınırlamalar

• Karmaşıklık: Event modelleme, schema evolution, idempotency ve distributed tracing zorlayıcıdır.
• Tutarlılık: Eventual consistency tasarım yükü getirir; yanlış modelleme veri tutarsızlıklarına yol açar.
• Operasyonel yük: Broker yönetimi, retention, partitioning ve skalalandırma opsiyonları yönetimsel iş yükü getirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Event schema'larını registry ile yönetin ve uyumluluk kuralları (backward/forward) uygulayın.
• Event'leri idempotent ve self‑describing yapın; correlation id, causation id gibi meta alanları dahil edin.
• Service SLAs'ını, retention ve partitioning stratejilerini açıkça tanımlayın.

Performans optimizasyonu

• Partitioning ve keying stratejileri ile hot‑key problemlerini azaltın.
• Consumer paralelleştirmesini ve backpressure mekanizmalarını kullanın.
• Materialized views ve cache'leri read‑heavy operasyonlar için tercih edin.

Güvenlik

• Event broker'ı için kimlik doğrulama, authorization ve encryption (in‑transit & at‑rest) uygulayın.
• Event payload içinde hassas veriyi tutmayın; referans veya token kullanın ve access control uygulayın.

Ölçeklenebilirlik ve operasyon

• Observability: trace propagation, structured logging ve metrics ile uçtan uca görünürlük sağlayın.
• Disaster recovery ve data retention politikalarını belirleyin; event store replicasyonu ve cross‑region replikasyonu planlayın.

8. SIK YAPILAN HATALAR

• Event tanımlarını yetersiz düşünmek — semantik olarak net olmayan event'ler tüketicileri zorlar.
• Idempotency ve deduplication stratejilerini atlamak — at‑least‑once işleme sonucu hatalı yan etkiler oluşur.
• Schema evolution'ı yönetmemek — eski ve yeni tüketiciler arasında kırılmalar olur.
• Observability eksikliği — event flow'u izlenmediğinde root cause analysis zorlaşır.
• Broker'ı tek hata noktası (SPOF) bırakarak resiliency tasarlamamak.

9. GELECEK TRENDLER

1. Event mesh: Farklı cloud ve cluster'lar arasında event routing ve federation sağlayan katmanların yükselişi.
2. AI destekli event pattern discovery: Anomali tespiti ve event korelasyonunda makine öğrenmesi uygulamaları.
3. Serverless streaming: Sunucusuz platformlarda event processing modell erinin daha geniş kullanımı.
4. Data mesh ve event driven data products: Data mesh konsepti ile domain'e özel event driven data ürünleri yaygınlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Event Driven Architecture her projeye uygun mu?

   Hayır. EDA, gerçek zamanlılık, gevşek bağlılık ve yüksek throughput gerektiren sistemler için uygundur. Küçük projelerde getirdiği karmaşıklık maliyeti aşabilir.

2. 2. Event sourcing ve CQRS aynı şey mi?

   Hayır. Event sourcing, durumun event'ler olarak saklanmasıdır. CQRS, okuma ve yazma yollarını ayıran bir desendir. İkisi birlikte kullanılabilir ancak birbirlerinden bağımsızdırlar.

3. 3. Hangi broker'ı seçmeliyim?

   Seçim ihtiyaçlarınıza bağlıdır: yüksek throughput ve durable log için Kafka/Pulsar; düşük gecikme, routing esnekliği için RabbitMQ; managed çözümler için AWS Kinesis, Google Pub/Sub değerlendirilebilir.

4. 4. Delivery garantileri nasıl belirlenir?

   İş gereksinimleri, toleranslar ve idempotency yeteneğinize göre at‑least‑once veya at‑most‑once tercih edilir. Exactly‑once genelde yüksek maliyetlidir ve dikkatle değerlendirilmelidir.

5. 5. Event schema değişiklikleri nasıl yönetilmeli?

   Schema registry kullanın, backward ve forward compatibility ilkelerini takip edin ve tüketicileri etap etap güncelleyin. Feature flags ve versioned topics stratejileri yardımcı olabilir.

6. 6. Idempotency nasıl uygulanır?

   Her event'e unique id ekleyin ve tüketicide işlenmiş id'leri saklayın; idempotent iş mantıkları yazın. Ayrıca deduplication mekanizmaları broker veya processing layer'da sağlanabilir.

7. 7. Event replay ne zaman kullanılır?

   Hata kurtarma, yeni tüketicilerin backfill işlemleri, analytics pipeline yeniden hesaplama veya migration senaryolarında event replay kullanılır.

8. 8. Observability için en iyi uygulamalar nelerdir?

   Trace propagation (correlation id), structured logging, consumer lag monitoring ve end‑to‑end metrics toplayın. Ayrıca schema evolution ve contract uyumluluğunu izleyin.

Anahtar Kavramlar

Event

Sistemdeki anlamlı değişiklik bildirimi.

Event Store

Olayların kronolojik olarak saklandığı dayanıklı log.

Saga

Distributed transaction yerine adım adım yürütülen iş akışı ve telafi mekanizmaları.

CQRS

Okuma ve yazma yollarını ayıran desen; performans ve model karmaşasını azaltır.

Schema Registry

Event formatlarının merkezi yönetildiği ve versionlandığı servis.

Öğrenme Yol Haritası

1. 0–1 ay: Messaging temelleri, publish/subscribe modelleri, broker temel kavramları ve basit producer/consumer uygulamaları.
2. 1–3 ay: Kafka/Pulsar veya RabbitMQ üzerinde derinleşin; partitioning, retention, consumer groups ve offset management gibi konuları öğrenin.
3. 3–6 ay: Event sourcing ve CQRS desenlerini örnek uygulamalarla deneyin; schema registry (Avro/Protobuf) ve idempotency stratejilerini uygulayın.
4. 6–12 ay: Stream processing (Kafka Streams, Flink), sagalar ve workflow motorları (Temporal, Cadence) ile gerçek dünya senaryolarını uygulayın; production‑grade observability ve DR stratejileri oluşturun.