1. GİRİŞ

Streaming architectures (akış tabanlı mimariler) modern veri uygulamalarında, düşük gecikmeli analitik ve gerçek zamanlı karar alma ihtiyaçlarının omurgasını oluşturur. Log, event ve telemetri gibi sürekli akan veriler işlenip, analiz edilip, anlık aksiyonlara dönüştürüldüğünde işletmeler daha hızlı ve akıllı hareket edebilir. Bu yazıda streaming mimarilerinin neden bugün kritik olduğunu, hangi problemlere çözüm sunduğunu ve hangi tasarım kararlarının nasıl alındığını mühendis perspektifinden detaylı biçimde ele alacağız.

Bu konu neden bugün önemli?

Veri hacmi ve çeşitliliği arttıkça batch‑only yaklaşımlar gecikme (latency) ve taze veri (freshness) açısından yetersiz kalıyor. Gerçek zamanlı kişiselleştirme, fraud detection, operasyonel telemetri ve online ML inference gibi kullanım senaryoları anlık veri işleme gerektiriyor. Bulut servisleri, managed streaming çözümleri ve open‑source projeler (Kafka, Flink, Pulsar) ekosisteminin olgunlaşması, streaming mimarilerini erişilebilir ve üretime hazır hâle getirdi.

Kimler için önemli?

• Veri mühendisleri ve platform ekipleri
• Backend geliştiriciler ve SRE/DevOps
• ML mühendisleri (online feature pipelines, model serving)
• Ürün yöneticileri ve iş analistleri — anlık içgörü ve aksiyon gerektiren süreçler

Hangi problemleri çözüyor?

• Gerçek zamanlı olay işleme ve anında karar döndürme
• Streaming ETL, continuous enrichment ve low‑latency aggregation
• Event sourcing ve audit‑ready event log'ları ile geçmişe dönük analiz ve replay

2. KAVRAMSAL TEMELLER

Akış mimarisini doğru kurmak için bazı temel kavramlar ve terminolojiyi netleştirmek gerekir. Bu bölüm mimarınızın ortak dilini oluşturacak.

2.1. Temel Tanımlar

• Event: Sistemde meydana gelen bir durum değişikliğini temsil eden atomik veri birimi.
• Stream: Zaman içinde sıralı event akışı.
• Event Broker: Event'leri persist eden, partitioning ve retention sağlayan katman (örn. Kafka, Pulsar).
• Stream Processor: Event akışını tüketip transformasyon, aggregation veya zenginleştirme yapan motor (Flink, Kafka Streams, Spark Structured Streaming).
• Exactly‑once / At‑least‑once / At‑most‑once: Mesaj teslim (delivery) garantileri ve yan etkilerinin nasıl ele alınacağına dair modeller.
• Windowing: Zaman veya sayıya dayalı event gruplama (tumbling, sliding, session)
• Stateful vs Stateless: Geçmiş durum tutan işlemler (joins, aggregates) veya yalnızca tek event'e bağımlı işlemler.

2.2. Temel Bileşenler

• Producers: Event oluşturan kaynaklar (uygulamalar, sensörler, DB CDC).
• Brokers / Topics: Event'lerin tutulduğu mantıksal kanallar.
• Stream Processors / Consumers: Event'leri işleyen uygulama katmanları.
• State Store: İşlem durumunu saklayan backend (RocksDB, distributed KV stores).
• Sink: İşlenmiş verinin yazıldığı hedefler (data lake, data warehouse, caches, downstream services).

3. NASIL ÇALIŞIR? (TEKNİK MİMARİ ve TASARIM)

Bu bölümde streaming mimarisinin teknik yapı taşlarını, veri akışını ve kritik tasarım kararlarını detaylandıracağız. Başarı, doğru broker seçimi, partitioning, state yönetimi ve izlenebilirlikle yakın ilişkilidir.

3.1. Mimarinin Yüksek Seviyesi Katmanları

• Ingest Layer: Event kaynaklarını toplayan katman — HTTP endpoints, SDK'lar, CDC connectors, IoT gateways.
• Message Broker: Durable, ordered ve partitioned log; retention ve compaction politikaları burada belirlenir.
• Processing Layer: Stream processing engine'leri — stateless operations, stateful aggregations, joins, pattern detection.
• Serving Layer: Low‑latency reads için caches (Redis), feature stores veya materialized views.
• Storage / Sink: Data lake, OLAP, or other sinks for long‑term storage, batch processing and reporting.

3.2. Broker Seçimi ve Konfigürasyon

Broker seçimi mimarinin merkezidir. Değerlendirilecek kriterler:

• Throughput ve latency hedefleri
• Retention ve tiered storage (Pulsar’in tiered storage veya Kafka + S3)
• Exactly‑once support ve transactional özellikler
• Operational maturity, tooling ve ekosistem (Connectors, MirrorMaker, etc.)

3.3. Partitioning ve Key Design

Partition key doğru seçilmezse hot‑key problemleri ortaya çıkar. İyi tasarım:

• Yükü mümkün olduğunca eşit dağıtacak key stratejileri seçer
• Ordering gereksinimini minimal tutar veya per‑key ordering ile sınırlı tutar
• Repartition maliyetini azaltmak için başlangıçta doğru granülerlik belirler

3.4. State Management ve Fault Tolerance

Stateful işlemlerde durability için state backend ve checkpointing gerekir. Tasarım unsurları:

• Local embedded state (RocksDB) + remote checkpoint store (S3) kombinasyonu
• Checkpoint interval ve snapshot boyutu — sık checkpoint düşük RTO sağlar ama I/O yükü arttırır
• Exactly‑once semantics için idempotent sinks veya transactional write (Kafka transactions) kullanımı

3.5. Windowing, Time Semantics ve Watermarks

Event time processing gerçek dünyadaki gecikmeleri (late events) düzgünce ele almak için önemlidir. Watermarks, late event toleransı ve window türleri (tumbling/sliding/session) uygulamanın ihtiyacına göre seçilir.

3.6. Delivery Semantics ve Idempotency

Mesaj teslim garanti modelinin seçimi iş mantığına doğrudan etki eder. At‑least‑once dağıtımda duplicate etkilerini azaltmak için idempotency; exactly‑once için ise broker+processor koordinasyonu veya transactional sink'ler gerekir. Genelde pragmatic yaklaşım at‑least‑once + deduplication/idempotency olmaktadır.

3.7. Observability ve Monitoring

Streaming sistemlerin izlenmesi özel metrikler gerektirir:

• End‑to‑end latency, per‑stage latency histograms
• Consumer lag ve partition skew
• Checkpoint duration, state size, restore time
• DLQ rate, retry counts ve poison message göstergeleri

4. GERÇEK DÜNYA KULLANIMLARI

Aşağıda streaming mimarilerinin yaygın sektör kullanımları ve örnek vaka analizleri bulunmaktadır. Bu örnekler, hangi desenin hangi problem için uygun olduğunu gösterir.

Netflix — Personalization ve Telemetry

Kullanıcı event’leri düşük gecikme ile toplanıp, feature pipeline'larına gönderilir. Real‑time feature üretimi ve A/B test sonuçlarının anlık analizi kullanıcı deneyimini artırır. Netflix, yüksek throughput için partitioning ve backpressure stratejilerini etkin kullanır.

Uber — Dispatch ve Pricing

Dispatch kararları anlık veriye bağlıdır. Uber, geo‑aware partitioning, locality ve stateful stream processing kullanarak düşük gecikmede güvenilir kararlar alır.

Amazon — E‑commerce Event Streams

E‑commerce olayları (checkout, inventory) event stream'lerine yazılır. Fraud detection, inventory reconciliation ve personalization için stream processing kullanılır. Kinesis gibi managed hizmetler ile operational yük azaltılır.

OpenAI — Telemetry ve Inference Pipelines

Model inference talepleri ve telemetri gerçek zamanlı toplanır. Stream architectures ile latency, throughput ve model routing optimizasyonu sağlanır.

Stripe — Ödeme İşlemleri ve Fraud

Payment event'leri gerçek zamanlı işlenerek fraud scoring yapılır. Çok düşük gecikme ve yüksek kesinlik gereksinimleri nedeniyle idempotency, event ordering ve strict observability ön plandadır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Anlık içgörüler ve hızlı aksiyon yeteneği
• Online ML inference ve personalization ile kullanıcı deneyimi iyileştirme
• Event sourcing ile audit trail ve replay yetenekleri

Sınırlamalar

• Operational complexity: checkpointing, rebalancing, state size yönetimi gibi operasyonel zorluklar
• Maliyet: replication, provisioned throughput ve storage maliyetleri artabilir
• Hatalı tasarımda tutarsızlık: hot keys, backpressure eksikliği ve yanlış partitioning ciddi sorunlara yol açar

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo yaygın streaming teknolojilerini avantaj ve dezavantajları ile karşılaştırır. Doğru seçim uygulama gereksinimlerine bağlıdır.

7. EN İYİ PRATİKLER

Production streaming sistemler yüksek dikkat, test ve operasyonel disiplin gerektirir. Aşağıdaki pratikler, sisteminizi daha dayanıklı ve yönetilebilir kılacaktır.

Production Kullanımı

• Event şemasını (Avro/Protobuf/JSON Schema) zorunlu kılın; schema registry ile sürümleme yapın.
• Idempotency, deduplication ve at‑least‑once/ transactional yaklaşımlarını açıkça tanımlayın.
• Backpressure, throttling ve retry politikalarını hem producer hem consumer tarafında uygulayın.

Performans Optimizasyonu

• Partition key design üzerinde zaman harcayın; hot key tespitini otomatikleştirin.
• State store boyutunu izleyin; RocksDB tuning ve compaction ayarlarını optimize edin.
• Batching/micro‑batch trade‑offs: küçük mesajlar ağ maliyetini artırır, büyük batch'ler latency'yi artırır.

Güvenlik

• Broker ve endpoint'ler arasında TLS/mTLS kullanın; RBAC/ACL ile erişimi sınırlandırın.
• PII içeren event'ları masking veya tokenization ile koruyun; audit log tutun.

Observability ve Operasyon

• End‑to‑end tracing, per‑partition consumer lag ve checkpoint metriklerini tutun.
• DLQ ve poison message handling ile problemli event'leri izole edin.
• Chaos testing: partition, broker outage ve consumer crash senaryolarını düzenli test edin.

8. SIK YAPILAN HATALAR

• Event schema yönetimi olmadan hızlı geliştirme: compatibility problemleri üretime taşınır.
• Partitioning stratejisini düşünmeden uygulamak: hot key ve uneven load oluşur.
• Stateful işlemleri plansız scale‑out etmek: rebalancing maliyeti ve restore süreleri yüksek olur.
• Observability olmadan production'a çıkmak: root cause analysis zorlaşır.

9. GELECEK TRENDLER

AI‑Assisted Stream Optimization

ML modelleri dinamik partition önerileri, hot key tespiti, adaptive checkpointing ve anomali tespiti gibi optimizasyonlar sunacak. Bu otomasyonlar operational burden'ı azaltacaktır.

Serverless Stream Processing ve Edge Integration

Serverless stream işleme (event driven lambdas, managed stream engines) adoption arttıkça operasyonel yük azalacak; edge preprocessing ile gecikme ve ağ maliyetleri optimize edilecek.

Standards and Interoperability

CloudEvents, AsyncAPI ve OpenTelemetry gibi standartlar streaming ekosistemlerinin birlikte çalışabilirliğini artıracak. Bu, çoklu broker ve çoklu bulut senaryolarında entegrasyonu kolaylaştırır.