1. GİRİŞ

Veri akışı (data streaming) günümüzde hemen her ölçekte yazılım sisteminin temel bileşeni hâline geldi. Geleneksel batch‑odaklı yaklaşım, toplu periyotlarla veri işlemek üzerine kuruluyken; modern uygulamalar anlık içgörü, düşük gecikmeli reaksiyon ve online karar mekanizmaları talep ediyor. Bu nedenle veri akışı mimarileri; telemetri, kullanıcı etkileşimleri, IoT sensörleri, finansal işlemler ve ML servisleri gibi senaryolarda kritik rol oynuyor.

Bu neden bugün önemli?

• Gerçek zamanlı iş kararları (fraud detection, personalization, monitoring) business değerini artırıyor.
• ML sistemlerinin online scoring ve feature serving ihtiyaçları düşük gecikme gerektiriyor.
• Bulut‑native ve mikroservis mimarileriyle birlikte event‑driven entegrasyonlar öne çıkıyor.

Kimler için önemli?

• Veri mühendisleri, MLOps ekipleri ve platform mühendisleri — akış tabanlı veri altyapısı tasarımı ve işletimi
• Yazılım mimarları ve CTO'lar — sistem kararları, ölçeklenebilirlik ve maliyet optimizasyonu
• Veri bilimciler ve ürün ekipleri — anlık veri akışıyla ürün deneyimleri ve modeller

2. KAVRAMSAL TEMELLER

2.1 Data streaming nedir?

Data streaming, verinin üretildiği noktadan tüketildiği noktaya sürekli olarak akmasını ve bu akış üzerinde düşük gecikmeli işlemlerin yapılmasını sağlar. Event (olay) temel atomiktir; her event bir zaman damgası, anahtar ve payload içerir. Streaming sistemi, yüksek hacimli event'leri güvenilir, sıralı ve ölçeklenebilir şekilde taşımayı ve işlemeyi hedefler.

2.2 Temel terminoloji

• Event: Sistem içinde gerçekleşen atomik eylem (örn. ödeme, tıklama, sensör ölçümü).
• Stream: Zaman sıralı event dizisi.
• Topic / Stream: Broker üzerinde event'lerin mantıksal ayrımı (Kafka topic gibi).
• Producer / Consumer: Event üreten ve tüketen roller.
• Broker: Event'leri saklayan ve tüketicilere ileten sistem (Kafka, Pulsar, Kinesis).
• Processing engine: Stream üzerinde transformasyon, agregasyon ve stateful computation yapan motor (Flink, Kafka Streams, Beam).
• Windowing: Event'leri zaman bazlı gruplama tekniği (tumbling, sliding, session).
• Exactly‑once / At‑least‑once: Teslimat ve işleme garantileri.

2.3 Bileşenler

• Ingestion (Collector): Veriyi kaynaklardan alır (agents, HTTP gateway, SDK).
• Message Broker: Yüksek performanslı, dayanıklı ve partition'lanabilir veri taşıyıcı.
• Stream Processing: Gerçek zamanlı dönüşümler, enrich, window ve stateful computation.
• Storage / Sink: İşlenmiş verinin kalıcı saklandığı yer (data lake, warehouse, OLAP, feature store).
• Serving layer: Online cache, feature store veya API ile hızlı erişim sağlar.

3. NASIL ÇALIŞIR?

3.1 Mimari desenleri

Streaming mimarileri kullanım senaryosuna göre farklı desenler izler. En yaygın olanları Lambda, Kappa ve event‑driven microservice mimarileridir.

Lambda mimarisi

Lambda yaklaşımı, hem stream hem batch işleme katmanlarını eş zamanlı kullanır. Hızlı, düşük gecikmeli sonuçlar için stream motoru; kesin ve gerçeğe yakın analizler için batch katmanı çalışır. Dezavantajı iki farklı kod/iş mantığına sahip olmaktır.

Kappa mimarisi

Kappa mimarisi tek bir stream işlem hattı kullanarak hem gerçek zamanlı hem geçmişe dönük yeniden hesaplama ihtiyaçlarını karşılamayı amaçlar. Tüm veri akışları bir broker üzerinden kaydedilip yeniden oynatılarak batch ihtiyacı da stream ile çözülür. Kappa, operasyonda tutarlılık sağlar ancak stream processing altyapısının olgun olmasını gerektirir.

Event‑driven microservices

Mikroservisler event bus üzerinden haberleşir; domain‑driven design ile bounded context'ler arasında asenkron iletişim kurulur. Bu yaklaşım, sistem bağımsızlığını ve esnekliğini artırır fakat event modeling ve versioning karmaşıklığı getirir.

3.2 Veri akışı ve iş mantığı

Tipik akış: kaynak → ingestion → broker → processing → sink/serve. Processing aşamasında validation, enrichment (metadata ekleme), deduplication, aggregation, windowing ve join işlemleri yapılır. Event time semantics (event time vs processing time) kritik bir karar noktasıdır; geç gelen veriler ve watermarks mekanizması ile ele alınır.

3.3 Teslimat garantileri ve idempotency

Exactly‑once garantisi ideal olsa da operasyonel maliyet ve altyapı karmaşıklığı arttırır. Birçok sistem at‑least‑once ile çalışıp idempotent consumer tasarımıyla side effect'lerden kaçınır. Streaming engine'lerin checkpointing ve transactional writes mekanizmaları bu sorunları hafifletir.

3.4 State management ve checkpoint

Stateful processing, sessionization ve rolling aggregation gibi ihtiyaçlar için state store gerekir. State'in düzenli snapshot'ları (checkpoint) alınmalı ve recovery mekanizmaları test edilmelidir. RocksDB gibi local state backend'ler veya managed state store çözümleri kullanılabilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — personalization ve telemetry

Netflix gerçek zamanlı event pipeline'ları kullanarak izleme davranışlarını, oynatma metriklerini ve etkileşimleri anlık izler. Bu veriler recommendation modellerini güncellemek ve A/B testleri sonuçlarını hızlı almak için kullanılır.

4.2 Uber — dispatch, surge ve routing

Uber gerçek zamanlı konum, talep ve arz verilerini işleyerek dispatch kararları verir. Stream processing ile latency kritik kararlar (matching, surge pricing) anlık hesaplanır; stateful ve event time semantics bu uygulamalarda merkezi rol oynar.

4.3 Financial services — fraud detection

Finans sektöründe işlem bazlı event akışı, anlık fraud detection ve risk scoring çözümlemeleri gerektirir. Çok düşük gecikmeli scoring motorları ve streaming feature computation finansal doğruluk için gereklidir.

4.4 AdTech ve real‑time bidding

Reklam teknolojileri (RTB) milisaniye seviyesinde latency gerektirir. Stream pipeline'lar teklif (bid) verilerini işler, model scoring yapar ve real‑time decision'ı verir. Bu alanda performans optimizasyonu ve optimizasyonlu serialization kritik önemdedir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Gerçek zamanlı tepki: fraud, personalization, monitoring gibi iş değerlerini anında gerçekleştirme.
• Esneklik: event‑driven entegrasyon ile sistemler daha gevşek bağlı (loosely coupled) olur.
• İyileştirilmiş gözlemlenebilirlik: sürekli telemetri ile olayların kaynağı hızlı tespit edilir.

Sınırlamalar

• Operasyonel karmaşıklık: state yönetimi, exactly‑once ve backpressure zorlukları.
• Maliyet: düşük gecikme hedefli altyapı (yüksek throughput) maliyetli olabilir.
• Versiyonlama ve schema evolution: event schema değişiklikleri downstream kırılmalara yol açabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Tasarım ve üretime alma

• Event contract: Şemalar açıkça tanımlanmalı ve schema registry (Avro/Protobuf/JSONSchema) kullanılmalıdır.
• Detect‑only rollout: Yeni event veya policy değişiklikleri önce detect‑only modunda izlenmelidir.
• Idempotent consumers: Side effect'leri tekrar eden event'lere karşı dayanıklı hale getirin.
• Backpressure handling: Tüketici yavaşsa üretimi throttling veya buffering ile koruyun.

7.2 Performans optimizasyonu

• Partitioning stratejisi: Key seçimi partitioning performansını belirler; hot key problemlerini önceden analiz edin.
• Serialization: Protobuf/Avro gibi kompakt binary formatlar kullanın.
• Locality & affinity: Stateful iş yüklerini veri lokasyonuna yakın çalıştırın (same region/zone).

7.3 Güvenlik ve compliance

• Encryption in transit & at rest, ACL ve IAM politikaları uygulayın.
• PII detection ve masking: Stream içinde hassas veriyi tespit edip maskeleyin.
• Audit ve lineage: event provenance ve immutable loglarla denetime hazır olun.

8. SIK YAPILAN HATALAR

• Schema evrimi planı olmadan değişiklik yapmak: downstream kırılmalar oluşur.
• Exactly‑once beklentisiyle gereksiz kompleksite: idempotency ile daha basit çözümler yeterli olabilir.
• Observability eksikliği: consumer lag, checkpoint durumu, state büyüklüğü takip edilmezse problemlere geç müdahale edilir.
• Testing yetersizliği: replay, chaos ve load testleri olmadan production'a geçmek risklidir.

9. GELECEK TRENDLER

9.1 Stream‑native veri platformları

Lakehouse ve stream‑native platformlar (kappa‑first yaklaşımlar) veri mühendisliği deneyimini birleştirerek gerçek zamanlı ve tarihsel veriyi aynı çatı altında işleme eğiliminde. Transactional stream storage (e.g. Apache Kafka with Tiered Storage) daha fazla benimseniyor.

9.2 Serverless stream processing ve edge streaming

Serverless streaming çözümleri ve edge computing, düşük işletme maliyeti ile düşük gecikmeli işleme kombinasyonu sunacak. Ancak stateful uygulamaların bu modellere adapte edilmesi yeni tasarım kalıpları gerektirecek.

9.3 AI‑driven stream processing

Streaming pipeline'larda AI destekli anomali tespiti, adaptive windowing ve predictive scaling daha yaygın kullanılacak. Bu, otomatik remediasyon ve kaynak optimizasyonu sağlar ama model drift ve explainability konularını beraberinde getirir.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Streaming mi yoksa batch mi seçmeliyim?

   İş gereksinimi belirleyicidir. Düşük gecikme, anlık karar veya online model scoring varsa streaming; toplu raporlama ve maliyet optimizasyonu gerekiyorsa batch tercih edilir.

2. 2. Kappa mı Lambda mı daha iyi?

   Kappa basitlik ve tek kod tabanı avantajı sağlar; ancak altyapınız stream‑oriented olmalı. Lambda, geçmiş ve gerçek zamanlı sonuçları ayrı optimize etme olanağı verir. Organizasyonel olgunluğa göre karar verin.

3. 3. Exactly‑once ne zaman gereklidir?

   Side effect içeren işlemler (ödeme, debit/credit) için güçlü semantic gerekebilir. Analitik veya idempotent operasyonlarda at‑least‑once yeterli olabilir ve daha düşük maliyetlidir.

4. 4. State yönetimini nasıl ölçeklendiririm?

   State TTL, compaction, incremental snapshots ve state sharding kullanın. RocksDB tabanlı local store veya managed state store çözümlerini değerlendirin.

5. 5. Hot key problemi nedir ve nasıl çözülür?

   Tek bir anahtarın çok yüksek trafiğe maruz kalması partition dengesizliğine yol açar. Çözüm: key salting, dynamic partitioning veya alternative aggregation stratejileri.

6. 6. Stream pipeline'larda test stratejisi nasıl olmalı?

   Unit, integration, contract ve end‑to‑end replay testlerini kullanın. Chaos ve load test'leri ile recovery senaryolarını doğrulayın.

7. 7. Hangi araçlar popüler?

   Broker: Apache Kafka, Pulsar, Kinesis. Processing: Flink, Kafka Streams, Spark Structured Streaming, Apache Beam. Orchestration: Airflow, Dagster, Prefect. Serialization: Avro, Protobuf, JSON Schema.

8. 8. Veri güvenliği için öncelikler nelerdir?

   Encryption, ACL/IAM, PII masking, audit logs ve immutable provenance uygulamalarını önceliklendirin.

Anahtar Kavramlar

• Stream: Sürekli akan ve zaman sıralı event dizisi.
• Broker: Event'leri saklayan ve tüketiciye ileten sistem (örn. Kafka).
• Windowing: Zaman bazlı event gruplama metodu.
• Watermark: Late arrivals yönetmek için kullanılan mekanizma.

Öğrenme Yol Haritası

1. 0–1 ay: Temel dağıtık sistemler, mesajlaşma kavramları, Linux ve ağ bilgisi.
2. 1–3 ay: Kafka producer/consumer, temek Flink veya Beam örnekleri, schema registry ve Avro/Protobuf ile çalışma.
3. 3–6 ay: Stateful processing, checkpointing, windowing, watermarks ve replay senaryoları üzerinde deneyim.
4. 6–12 ay: Production readiness: monitoring, SLO'lar, chaos testing, disaster recovery ve cost optimization projeleri.