1. GİRİŞ

Event streaming (olay akışı) sistemleri, modern veri‑yoğun uygulamaların gerçek zamanlı ihtiyaçlarını karşılamak için ortaya çıkan temel altyapılardan biridir. Geleneksel batch tabanlı veri işleme yaklaşımları, anlık analiz, düşük gecikmeli reaktif deneyimler ve yüksek hacimli telemetri gereksinimlerini karşılamakta yetersiz kalırken, event streaming platformları bu boşluğu doldurur. Özellikle mikroservis mimarileri, IoT, telemetri, izleme, finansal işlemler ve MLOps gibi alanlarda event stream'ler veri akışının omurgasını oluşturur.

Bu konu neden bugün önemli?

• Gerçek zamanlı veri kararları (real‑time analytics) ve anlık kullanıcı deneyimleri beklentisi artıyor.
• Büyük veri hacimleri ve sürekli yayılan telemetri, düşük gecikmeli stream işleme ihtiyacını doğuruyor.
• Microservice ve event‑driven mimarilerin yaygınlaşmasıyla servisler arası loose coupling ve durable messaging gereksinimleri öne çıkıyor.

Kimler için önemli?

• Platform mühendisleri ve veri mühendisleri
• Backend geliştiriciler ve sistem mimarları
• Operasyon ekipleri (SRE/DevOps) — ölçekleme, DR ve gözlemlenebilirlik sorumluluğu

Hangi problemleri çözüyor?

• Yüksek throughput ile dayanıklı veri iletimi
• Event replay, backfill ve audit kabiliyeti
• Stream processing ile gerçek zamanlı dönüşüm ve materialized view oluşturma

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

Event (Olay)

Sistemde meydana gelen anlamlı durum değişikliği. Genellikle immutable (değiştirilemez) ve timestamp içerir.

Stream

Zamanla sıralı event koleksiyonu; topic/stream partition'larına yazılır ve tüketiciler tarafından okunur.

Broker

Event'lerin kalıcı olarak yazıldığı ve dağıtıldığı sunucu yazılımı (Apache Kafka, Apache Pulsar, AWS Kinesis, Google Pub/Sub vb.).

Partition

Topic'in paralel okunabilir parçası; yatay ölçeklenmeyi ve ordered processing'i sağlar.

Offset

Partition içindeki event'in sırası veya index'i; tüketicilerin tüketim pozisyonunu izlemek için kullanılır.

2.2 Teslim garantileri

• At‑most‑once: Kaybı kabul eden, maksimum bir kez iletim.
• At‑least‑once: Teslim güvencesi yüksek, ancak duplicate ihtimali vardır; idempotency gerekir.
• Exactly‑once: Hem broker hem de processing layer ile koordinasyon gerektirir; dikkatle uygulanmalıdır.

2.3 Core bileşenler

• Producers: Event üreten uygulamalar
• Brokers: Event'leri saklayan ve yöneten altyapı
• Consumers: Event'leri işleyen uygulamalar
• Stream Processors: Stateful/stateless transformasyon yapan bileşenler (Kafka Streams, Flink, Spark Streaming)
• Schema Registry: Event formatlarının merkezi yönetimi

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

3.1 Temel akış

Producer bir eventi broker'a publish eder. Broker event'i disk tabanlı bir log'a append eder ve partition/replica politikasına göre çoğaltır. Consumer grubu (consumer group) aynı topic partition'larını paylaşır; her partition yalnızca gruptaki tek bir tüketici tarafından işlenir. Offset'ler yönetilir; consumer ister otomatik commit yapar ister manuel commit ile kontrollü ilerler.

3.2 Partitioning stratejileri

Partitioning, paralel okuma ve ordered processing arasında trade‑off yaratır. Anahtar (key) bazlı partitioning, aynı key'e sahip event'lerin sırayla işlenmesini sağlar. Ancak hot key problemleri ortaya çıkabilir: tek bir key çok fazla trafiğe neden olursa ilgili partition darboğaz olur. İyi bir strateji: event key'leri domain'e göre tasarlamak, composite key veya hash tabanlı dengeli dağılım kullanmaktır.

3.3 Replication ve durability

Brokerlar replica set'leriyle verinin dayanıklılığını sağlar. Örneğin Kafka'da replication factor ve ISR (in‑sync replicas) kavramları kritik önemdedir. Yüksek dayanıklılık için yeterli replica, doğru ACK konfigürasyonu ve monitoring şarttır. Cross‑region replication, DR senaryoları için kullanılır fakat gecikme ve maliyet etkileri vardır.

3.4 Retention ve compaction

Retention politikaları event log'un ne kadar süre tutulacağını belirler; disk maliyeti ve backfill yetenekleri bu politikayla dengelenir. Log compaction, topic bazında en son key state'ini saklayarak storage optimizasyonu sağlar — özellikle change‑log ve state‑store senaryolarında yararlıdır.

3.5 Delivery semantics ve idempotency

At‑least‑once işleme yaygındır; bu nedenle tüketicilerin idempotent olması gerekir. Idempotency token'ları, deduplication store'ları ve transactional writes (ör. Kafka transactions) kullanılarak duplicate etkileri azaltılabilir. Exactly‑once semantics (EOS) uygulamak istiyorsanız hem üretici hem de tüketici tarafında transactional mekanizmalar ve stream processing framework entegrasyonu gereklidir.

3.6 Stream processing ve state management

Stateful stream processing, sliding window, tumbling window, aggregations ve joins gibi işlemleri yapar. State store'lar (rocksdb, embedded stores) checkpointing ile persistent hale gelir. Checkpoint ve snapshot mekanizmaları fault recovery için kritik önemdedir.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Telemetry ve personalization

Netflix, kullanıcı davranışlarını, telemetriyi ve sistem metriklerini stream'leyerek anlık öneri mekanizmaları ve kalite analizi uygular. Yüksek throughput veri akışı ile müşteri deneyimini optimize eder.

Uber — Real‑time dispatch

Uber, konum, talep ve sürücü durumunu stream'leyerek gerçek zamanlı routing ve dispatch kararları alır. Çok düşük gecikmeli event processing, gecikme toleransını minimize etmeyi gerektirir.

Amazon — Order lifecycle ve inventory

Amazon benzeri e‑commerce platformlarında order event'leri, inventory güncellemeleri ve fulfilment pipeline'ları stream ile bağlanır. Event replay özellikleri reconciliation ve auditing için kullanılır.

Fintech — Trading ve reconciliations

Finansal sistemlerde düşük gecikme, kesinlik ve auditability gereklidir. Event streaming settlement, reconciliation ve real‑time risk monitoring için tercih edilir. Exactly‑once garantileri veya deterministik compensating logic kritik olabilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Gecikme (latency) düşük veri işleme: Stream processing real‑time kararlar almayı sağlar.
• Durability ve replay: Event log'lar sistemin geçmişini saklar; backfill ve hata kurtarma mümkün.
• Yatay ölçeklenebilirlik: Partitioning ile tüketim paralelleştirilebilir.

Sınırlamalar

• Operasyonel karmaşıklık: Broker cluster yönetimi, retention, rebalancing, partition leadership gibi operasyonel zorluklar vardır.
• Maliyet: Uzun retention, yüksek replication ve cross‑region replikasyon maliyetleri yükseltir.
• İzlenebilirlik karmaşası: End‑to‑end trace ve correlation id propagasyonu ihmal edilirse debugging zorlaşır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Topic ve partition tasarımını erken aşamada düşünün; hot key problemlerine karşı test yapın.
• Retention, replication ve ACK politikalarını iş SLA'larına göre belirleyin.
• Schema registry ve semantic versioning ile backward/forward uyumluluğu sağlayın.

Performans optimizasyonu

• Producers tarafında batching ve compression (snappy, lz4) kullanın.
• Consumer paralelleştirmesini partition count ile dengeleyin; thread pool ve backpressure politikası belirleyin.
• Stateful stream processor'larda local state store ve checkpoint tuning ile recovery hızını artırın.

Güvenlik

• Broker erişimini TLS, authentication (SASL, OAuth) ve ACL'lerle kontrol edin.
• Event payload içinde hassas veri tutmayın; token veya referans kullanın ve encryption at‑rest uygulayın.

Ölçeklenebilirlik ve operasyon

• Monitoring: partition lag, consumer throughput, broker metrics ve disk kullanımını izleyin.
• Capacity planning: retention ve expected throughput'u kullanarak disk ve ağ gereksinimlerini hesaplayın.
• DR: cross‑region replication ve disaster recovery playbook'ları oluşturun.

8. SIK YAPILAN HATALAR

• Topic parity ve partition sayısını yanlış belirlemek — sonradan değişiklik operasyonel zorlayıcı olabilir.
• Idempotency mekanizması ihmal edilmesi — duplicate işlenmeler veri hatalarına neden olur.
• Schema evolution kurallarını uygulamamak — tüketici kırılmaları ve veri uyumsuzlukları ortaya çıkar.
• Monitoring ve alert'leri yeterince kapsamlı kurmamak — consumer lag veya broker disk doluluğu geç fark edilir.

9. GELECEK TRENDLER

1. Event mesh: Farklı cloud ve cluster'lar arasında standartlaştırılmış event routing ve federation katmanları yaygınlaşacak.
2. Serverless streaming: Stream processing'in serverless modeline taşınması ile operasyonel yük azalacak.
3. AI destekli ops: Anomali tespiti, partition rebalancing önerileri ve otomatik kapasite planlama AI ile desteklenecek.
4. Transactional stream processing: Daha geniş exactly‑once ve transactional processing yetenekleri standart hale gelecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Event streaming mi yoksa message queue mu tercih etmeliyim?

   İhtiyaçlarınıza bağlı. Event streaming (Kafka/Pulsar) yüksek throughput, replay ve durable log gerektiren senaryolar için uygundur. Kısa ömürlü iş kuyrukları ve task dispatch için RabbitMQ veya managed queue hizmetleri daha uygun olabilir.

2. 2. Partition sayısını nasıl belirlerim?

   Beklenen maksimum throughput, consumer parallelizm hedefi ve disk/CPU kaynakları göz önüne alınarak hesaplanır. Ayrıca production testleri ile hot key davranışı doğrulanmalıdır.

3. 3. Retention nasıl planlanmalı?

   Backfill ihtiyaçları, compliance ve storage maliyeti göz önünde bulundurularak belirleyin. Tiered storage veya cold storage ile maliyet optimize edilebilir.

4. 4. Exactly‑once mümkün mü?

   Platform ve processing engine kombinasyonuna bağlı olarak kısmi veya tam exactly‑once sağlanabilir. Kafka transactions ve idempotent producers ile pek çok senaryo güvenli hale getirilebilir ancak dikkatli tasarım gerektirir.

5. 5. Schema değişikliklerini nasıl güvenle yönetirim?

   Schema registry, semantic versioning ve compatibility policy (backward/forward) kullanın. Tüketicileri etap etap güncelleyin ve feature flags ile yumuşak geçiş sağlayın.

6. 6. Broker hatası durumunda ne yapmalıyım?

   Monitoring ile lider‑follower durumu izleyin, ISR dışına çıkan replika nedenlerini inceleyin. DR planı ve cross‑region replication ile veri kaybı riski azaltılmalıdır.

7. 7. Stream processing için hangi araçları seçmeliyim?

   Küçük ve gömülü transformlar için Kafka Streams; güçlü stateful processing ve low‑latency için Flink; batch ve micro‑batch gereksinimler için Spark Streaming tercih edilebilir. Seçim throughput, state gereksinimi ve latency hedeflerine bağlıdır.

8. 8. Event streaming güvenli mi?

   Doğru konfigüre edildiğinde güvenlidir. TLS, authentication, authorization ve payload encryption uygulayın; hassas veriyi event içinde taşımaktan kaçının.

Anahtar Kavramlar

Partition

Topic'in paralel işlenebilir parçası; ordered processing ve paralelleşme sağlar.

Offset

Partition içindeki event konumu; tüketim pozisyonunu ifade eder.

Retention

Event log'un saklanma süresi; backfill ve replay yeteneklerini etkiler.

Compaction

Key bazlı en son state'in saklandığı storage optimizasyonu.

Schema Registry

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

Öğrenme Yol Haritası

1. 0–1 ay: Messaging ve publish/subscribe temelleri, basit producer/consumer uygulamaları.
2. 1–3 ay: Apache Kafka veya Pulsar üzerinde derinleşme; partitioning, retention, consumer groups, offset yönetimi öğrenin.
3. 3–6 ay: Stream processing (Kafka Streams, Flink), state management, checkpointing ve windowing desenlerini uygulayın.
4. 6–12 ay: Production ops: cluster yönetimi, monitoring, cross‑region replication, DR ve capacity planning deneyimi kazanın.