Yığın (Batch), akışın özel bir durumudur. İşletmenizin saatler yerine saniyeler içinde tepki vermesi gerektiğinde, sürekli veri akışı için tasarlanmış bir mimariye ihtiyacınız vardır.

Panolarınız, birileri onlara baktığında güncelliğini yitirmiş olur. Dolandırıcılık tespiti, ertesi sabah dolandırıcılığı yakalayan bir gece batch işi olarak çalışır. Envanter sayımları saatlik olarak güncellenir ve bu da fazla satışa neden olur. Sensör verileri toplanır ancak gecelik bir ETL'de analiz edilene kadar işlenmez. Verilerin kaynaklardan işleme ve tüketicilere kadar sürekli olarak, saniye altı gecikmeyle aktığı bir sisteme ihtiyacınız vardır — real-time analytics, canlı bildirimler, streaming AI inference ve sistemler arasında anında senkronizasyon.
Explore more design patterns and system architectures
Mimarlarımız, bu deseni kullanarak belirli gereksinimleriniz için sistemler tasarlamanıza ve oluşturmanıza yardımcı olabilir.
İletişime GeçinReal-time streaming architecture, verileri ayrık batch'ler yerine sürekli, sınırsız bir akış olarak işler. Event producers, bir streaming platform'a (Kafka, Kinesis, Pulsar) yayınlar. Stream processors (Flink, Kafka Streams, custom consumers), olayları uçuş sırasında dönüştürür, zenginleştirir, filtreler ve toplar. İşlenmiş sonuçlar tüketicilere iletilir: real-time dashboards (WebSocket), search indices (Elasticsearch), analytics databases (ClickHouse) ve downstream services. Change Data Capture (CDC), mevcut veritabanlarının uygulama değişiklikleri olmaksızın event sources olarak katılmasına olanak tanır.
Mimari dört katmandan oluşur. Event sources veri üretir — application events, database CDC streams, IoT telemetry, user clickstreams, external API webhooks. Streaming platform (Kafka), dayanıklı, sıralı, tekrar oynatılabilir olay depolaması sağlar. Stream processors konulardan tüketir, dönüşümler (filtering, enrichment, windowed aggregation, joins) uygular ve çıktı konularına veya sink'lere üretir. Consumers işlenmiş akışlara abone olur — WebSocket sunucuları tarayıcılara iter, connectors veritabanlarına yazar, alerting engines kuralları değerlendirir ve bildirimleri tetikler.
| Katman | Technologies |
|---|---|
| Akış | Apache Kafka (MSK, Confluent), Kinesis, Apache Pulsar, Redpanda |
| CDC | Debezium, AWS DMS, Maxwell |
| İşleme | Apache Flink, Kafka Streams, Benthos, custom consumers |
| Gerçek Zamanlı Teslimat | WebSocket (Socket.io), SSE, GraphQL Subscriptions |
| Analiz | ClickHouse, Apache Druid, Elasticsearch, TimescaleDB |
| Gözlemlenebilirlik | Kafka lag monitoring (Burrow), Flink metrics, custom latency tracking |
| Ne Zaman Kullanmalı | Ne Zaman Kaçınmalı |
|---|---|
| İş kararları saniye altı veri güncelliği gerektirdiğinde (dolandırıcılık, izleme, ticaret) | Saatlik/günlük güncellik ile batch processing, iş ihtiyacını karşılıyorsa |
| Birden fazla consumer aynı olay akışına ihtiyaç duyduğunda (fan-out, decoupled systems) | Tek bir producer ve tek bir consumer'ınız varsa — basit bir kuyruk yeterlidir |
| Hata ayıklama, yeniden işleme veya yeni consumer'lar oluşturmak için olay tekrarına (event replay) ihtiyacınız varsa | Veri hacmi düşükse (< 1K events/min) ve streaming infrastructure'ı haklı çıkarmıyorsa |
| Mevcut veritabanlarını kod değişikliği olmadan downstream systems'a senkronize etmek için CDC gerekiyorsa | Ekip dağıtık sistemler konusunda deneyimsizse — streaming önemli operasyonel karmaşıklık ekler |
MW, streaming sistemlerini "tekrar oynatma prensibi" ile tasarlar — her akış, belirli bir zamandan itibaren tekrar oynatılabilir olmalı, böylece yeni consumer'lar geçmiş verileri doldurabilir ve mevcut consumer'lar hata düzeltmelerinden sonra yeniden işleyebilir. Kafka dağıtımlarımız, şema evrim politikalarını (varsayılan olarak geriye dönük uyumlu), consumer lag uyarılarını (işletme açısından fark edilebilir bir gecikme haline gelmeden önce) ve otomatik yeniden deneme özellikli dead-letter topics'i içerir. Video analytics, IoT telemetry ve real-time dashboards için saniyede 500K+ olayı işleyen streaming pipelines oluşturduk.
Tek bir kod tabanı, yüzlerce kiracı, sıfır veri sızıntısı — her ölçeklenebilir SaaS işinin temeli.
MicrocosmWorks, günlük tabanlı mimarisi aynı veri akışını bağımsız olarak yeniden okuyan sınırsız tüketici grubunu desteklediği için, çoklu tüketici tekrarı, uzun saklama süreleri ve bulutlar arası taşınabilirlik ihtiyacı olan ekipler için Kafka'yı önermektedir. AWS ekosistemiyle sıkı bir şekilde entegre tam yönetilen bir hizmet istediğinizde ve veri saklama ihtiyaçlarınız 7 günden az, tüketici uygulama sayınız ise 10'dan az olduğunda Kinesis daha iyi bir seçimdir. Doğru tavsiyede bulunmak için mimari değerlendirmemiz sırasında özel gereksinimlerinizi – verim, saklama, tüketici modelleri ve operasyonel olgunluk – değerlendiriyoruz.
MicrocosmWorks, Redis gibi hızlı bir arama önbelleğinde depolanan olay parmak izlerini kullanan değişmez (idempotent) üreticiler, işlemsel tüketiciler ve tekilleştirme katmanlarının bir kombinasyonu aracılığıyla tam olarak bir kez semantiğini uygular. Kafka tabanlı sistemler için, Kafka'nın tüketici ofsetlerini ve üretici yazmalarını atomik olarak işleyen yerleşik işlemsel API'sinden yararlanırken, özel akış işlem hatları için tüketici tarafında tekilleştirme ile outbox paternini uyguluyoruz. Tüketicileri her zaman bir güvenlik ağı olarak değişmez (idempotent) olacak şekilde tasarlarız, böylece tam olarak bir kez mekanizmasında uç bir durum hatası olsa bile, bir olayın yeniden işlenmesi aynı sonucu verir.
MicrocosmWorks, alım, işleme ve çıkış (sink) yazmayı içeren akış işlem hatları için tipik olarak 50-200 ms uçtan uca gecikmeler sağlarken, Apache Flink veya Kafka Streams gibi bellek içi akış işlemcilerini kullanarak daha basit geçiş veya filtreleme iş yükleri için 10 ms'nin altında gecikmeler elde edilebilir. En büyük gecikme katkıda bulunanlar genellikle ağ atlamaları (network hops), serileştirme yükü (serialization overhead) ve çıkış yazma gruplaması (sink write batching) olup, bunları gecikme-verim denge tercihlerinize göre ayarlıyoruz. Mimari tasarımımız sırasında, her işlem hattı aşaması için açık gecikme SLO'ları (Service Level Objectives) belirler ve üretim ortamında p50, p95 ve p99 gecikmeleri takip eden izleme panoları oluştururuz.
MicrocosmWorks, üreticilerin mevcut tüketicileri bozmadan veri formatlarını geliştirebilmelerini sağlayan ileri ve geri uyumluluk kurallarını uygulayan şema kayıt defterlerini (genellikle Confluent Schema Registry veya AWS Glue Schema Registry) kullanır. Açık şema versiyonlaması ile Avro veya Protobuf serileştirmesini kullanırız, böylece her mesaj kendi kendini tanımlar ve üretildiğinden beri şema değişmiş olsa bile serileştirilebilir. CI/CD işlem hatlarımız, önerilen bir şema değişikliğinin alt akış tüketicilerini bozması durumunda dağıtımları engelleyen otomatik şema uyumluluk kontrollerini içerir.
MicrocosmWorks, bir üretim akış platformunu güvenilir bir şekilde sürdürmek için dağıtılmış sistemler, akış işleme çerçeveleri ve altyapı otomasyonu konularında deneyimli en az 2-3 mühendis önermektedir. Bu uzmanlığı şirket içinde oluşturmak istemeyen şirketler için, ekiplerimizin küme operasyonlarını, performans ayarlamalarını ve olaylara müdahaleyi yönettiği, geliştiricilerinizin ise akış işleme uygulamaları oluşturmaya odaklandığı 15-40$/saat karşılığında yönetilen akış platformu desteği sunuyoruz. Ayrıca, mevcut mühendislik ekibinizi 4-8 haftalık taahhütlerle Kafka, Flink veya Kinesis operasyonları konusunda yetkinleştiren eğitim programları da sağlıyoruz.