haber

Haber, yalnızca "yeni bilgi" anlamına gelmez. Teknik açıdan bakıldığında haber; yüksek frekanslı olay verilerinin toplanması, doğrulanması, sınıflandırılması ve milyonlarca istemciye düşük gecikmeyle dağıtılması sürecinin tamamıdır. Son yirmi yılda haber üretimi matbaadan canlı yayına, oradan anlık mobil bildirimlere ve otomatik özet akışlarına kaydı.

Modern bir haber platformunu değerlendirirken çoğu kişi başlıklara, yorumlara ve paylaşım sayılarına odaklanır. Biz ise bu yazıda işin görünmeyen tarafına bakacağız: dağıtık sistemler, yayın protokolleri, içerik doğrulama modelleri ve uyarı altyapıları. Çünkü her "son dakika" etiketi, arka planda bir dizi olayın tetiklendiği karmaşık bir yazılım mimarisinin sonucudur.

Haber artık yalnızca içerik değil; milisaniyeler içinde ölçeklenen, coğrafi olarak dağıtık ve sürekli doğrulanması gereken bir veri akışıdır. Bu yaklaşım, haber sistemlerini sıradan içerik yönetim araçlarından ayırır. Denver Mobile App Developer ekibi olarak üretim ortamlarında kurduğumuz haber toplayıcı API'lerinde, bu akış hattının her katmanını kendi gözlemlerimizle test ettik.

Haber Platformlarının Teknik Omurgası: Gerçek Zamanlı Veri Hatları

Bir haber platformunun kalbi, editörlerin yazdığı metinlerden çok önce atar. Kaynaklardan gelen sinyaller - ajans akışları, sosyal medya API'leri, hava durumu servisleri, borsa verileri, resmî kurum duyuruları - merkezi bir veri hattına bağlanır. Bu hatta genellikle Apache Kafka veya AWS Kinesis gibi dağıtık event streaming araçları kullanılır. Kafka'nın partition mantığı sayesinde haber başlıkları kaynak bazında paralel işlenebilir; bir kaynaktaki gecikme diğerlerini bloklamaz.

Canlı skor, seçim sonucu veya trafik kazası gibi hızlı değişen veriler için Redis gibi in-memory veri depoları devreye girer. Bizim kurduğumuz bir haber API'sinde, dakikada 40 binin üzerinde gelen JSON mesajını Kafka üzerinden tüketip Redis'te 120 saniyelik TTL ile saklamıştık. Bu yapı, istemci tarafında 50 milisaniyenin altında okuma gecikmesi sağladı. TTL süresi dolan kayıtlar ise PostgreSQL veya ClickHouse gibi kalıcı analitik depolara yazıldı.

Veri hattının bir diğer kritik parçası şema yönetimidir. Ajanslar farklı formatlarda veri gönderdiği için Avro veya Protobuf gibi serileştirme formatları kullanılır. Schema Registry olmadan yapılan bir entegrasyonda, alan adı değişikliği tüm tüketicileri sessizce bozabilir. Bu yüzden haber platformlarında "backward compatibility" yalnızca bir konfor değil, operasyonel bir zorunluluktur.

A Haber Gibi 7/24 Yayın Kanallarının Stream Mimarisi

A Haber gibi 7/24 canlı yayın yapan kanallar, kesintisiz bir video akışını coğrafi olarak dağıtık sunucular üzerinden milyonlarca izleyiciye ulaştırır. Bu süreçte ham uydu veya stüdyo sinyali önce bir kodlayıcıya gider. Kodlayıcı, videoyu farklı çözünürlük ve bit hızlarına dönüştürür: 1080p'den 240p'ye kadar çoklu bit hızı profilleri oluşturulur. Bu profiller, izleyicinin bant genişliğine göre otomatik seçilir; buna adaptive bitrate streaming denir.

Canlı yayın altyapısında en yaygın protokol HLS'dir (HTTP Live Streaming). RFC 8216'da tanımlanan HLS, videoyu kısa segmentlere böler ve bir manifest dosyası üzerinden istemciye sunar. Düşük gecikme gerektiren haber yayınları için LL-HLS (Low-Latency HLS) kullanılır. LL-HLS, segment süresini 2-6 saniyeden 1 saniyenin altına indirebilir. Ancak bu optimizasyon, CDN önbellek isabet oranını düşürebilir; bu yüzden yayın mühendisleri gecikme ile maliyet arasında sürekli bir denge kurar.

Yayın hattının tipik bileşenleri şunlardır:

• Canlı sinyal alımı ve SDI/NDI dönüşümü
• FFmpeg veya ticari donanım kodlayıcılarla çoklu bit hızı üretimi
• HLS/DASH paketleyici ve manifest oluşturucu
• Origin shield ve edge CDN katmanı
• DRM ve erişim kontrolü (Widevine, PlayReady, FairPlay)

Bu bileşenlerin her biri, haber kanalının yayın sürekliliğini doğrudan etkiler. Bir paketleyicideki bellek sızıntısı, yalnızca teknik bir arıza değil; aynı zamanda milyonlarca izleyicinin ekranının donması anlamına gelir.

Kırılma Haberlerinde Düşük Gecikme Mimarisi ve WebRTC/LL-HLS

Son dakika haberi, diğer içerik türlerinden farklı bir mühendislik profiline sahiptir. Kullanıcılar bir olayı sosyal medyadan öğrendikten 30 saniye sonra haber uygulamasında göremezse, platforma olan güven azalır. Bu nedenle kırılma haberi sistemleri, push notification servisleri ile canlı yayın altyapısını aynı olay döngüsünde birleştirir.

WebRTC, bu noktada HLS'den çok daha düşük gecikme sunar. MDN WebRTC API dokümantasyonu, peer-to-peer bağlantıların nasıl kurulduğunu ayrıntılı olarak açıklar. Ancak WebRTC'nin milyonlarca eşzamanlı izleyiciye ölçeklenmesi zordur; bu yüzden hibrit mimariler yaygınlaşmıştır. WebRTC, yalnızca editörler arası canlı önizlemede kullanılırken, son kullanıcıya LL-HLS veya WebTransport üzerinden ulaşılır.

Bizim üretim ortamında uyguladığımız yaklaşım, kırılma haberlerini üç katmana ayırmaktı: birincil kaynaktan gelen yapılandırılmış veri (JSON), ikincil olarak canlı video akışı ve üçüncül olarak mobil push bildirimi. Bu üç katman farklı gecikme bütçelerine sahiptir. Push bildirimi için 1 saniye, canlı yayın için 4 saniye, haber sayfası güncellemesi için ise 800 milisaniye hedefledik. Her katmanın SLO'su birbirinden bağımsız izlenir.

İçerik Doğrulama ve Dezenformasyonla Mücadelede Makine Öğrenmesi

Haber akışının hızı arttıkça yanlış bilginin yayılma hızı da artar. Profesyonel haber platformları, içerik yayınlanmadan önce otomatik doğrulama katmanları çalıştırır. Bu katmanlar; kaynak güvenilirlik skoru, görsel tersine arama, metin tutarlılığı ve zaman damgası analizi gibi sinyalleri birleştirir. Makine öğrenmesi burada karar destek sistemi olarak görev yapar; nihai karar genellikle insan editördedir.

Doğal dil işleme (NLP) kütüphaneleri - spaCy, Hugging Face Transformers, NLTK - başlık ve gövde metninden varlık çıkarımı yapar. Bir haber metninde geçen kurum, kişi, yer ve tarih bilgileri bir bilgi grafiğine bağlanır. Eğer başlık "X şirketi iflas etti" diyorsa ancak gövdede böyle bir ifade yoksa, model bu uyumsuzluğu bayraklandırır. Bu tür sistemler, editörlerin gözünden kaçabilecek hataları saniyeler içinde yakalar.

Güncel arama trendlerine baktığımızda "Fatma Betül Sayan Kaya", "Fatma Betül Sayan", "fon" ve "A Haber" gibi terimlerin aynı anda yükseldiği görülür. Bu, haber platformları için klasik bir varlık bağlama (entity linking) problemidir. Varlık tanıma modeli, "Fatma Betül Sayan Kaya" ile kısaltılmış hali "Fatma Betül Sayan"ı aynı düğümde birleştirmelidir. Aynı şekilde "fon" kelimesi finansal bağlamda farklı, kamuoyu tartışması bağlamında farklı anlam taşır. Bağlam sınıflandırıcı olmadan yapılan trend analizi, tamamen yanıltıcı sonuçlar üretebilir.

Haber Veri Akışlarında Gözlemlenebilirlik ve SRE Yaklaşımları

Bir haber platformunun çökmesi, yalnızca gelir kaybı değil aynı zamanda kamuoyunun doğru bilgiye erişiminin kesilmesidir. Bu yüzden haber altyapılarında gözlemlenebilirlik, Site Reliability Engineering (SRE) pratiğinin merkezine oturur. Prometheus resmi dokümantasyonu bu konuda sağlam bir başlangıç noktası sunar. Prometheus, Kafka consumer lag, Redis bellek kullanımı ve HTTP yanıt süreleri gibi metrikleri toplar; Grafana ise bunları görsel panellere dönüştürür.

Bizim haber API'sinde tanımladığımız temel SLO'lar şunlardı:

• Haber listesi endpoint'i için p99 gecikme
• Kırılma haberi bildirim uçtan uca gecikme
• Aylık %99,95 erişilebilirlik
• Kafka consumer lag

Bu eşiklerden herhangi biri aşıldığında, alertmanager otomatik olarak on-call mühendise sayfa çağrısı gönderir. Üretim ortamında, p99 gecikmesinin aniden yükselmesinin çoğu zaman veritabanı bağlantı havuzu tükenmesinden kaynaklandığını gördük. Bu nedenle connection pooling ayarlarını statik değil, trafik desenine göre dinamik ölçekleyen bir yapı kurduk.

Coğrafi Dağıtık Edge Network ve CDN Stratejileri

Bir haber platformunun performansı, kullanıcının coğrafi konumundan bağımsız olmalıdır. İstanbul'daki bir kullanıcı ile Berlin'deki bir kullanıcı aynı haber sayfasını açtığında, ikisi de aynı düşük gecikmeyi bekler. Bu beklenti, coğrafi dağıtık bir CDN mimarisi olmadan karşılanamaz. Cloudflare, Fastly veya Akamai gibi sağlayıcılar, statik varlıkları ve önbelleklenebilir API yanıtlarını kullanıcıya en yakın PoP (Point of Presence) üzerinden sunar.

Edge network tasarımında önemli bir karar, hangi içeriğin önbellekleneceğidir. Ana sayfa gibi yüksek trafikli ama hızlı değişen sayfalar, kısa TTL ile edge'de tutulabilir. Ancak kişiselleştirilmiş haber akışları genellikle önbelleklenemez; çünkü her kullanıcıya farklı içerik gösterilir. Bu tür dinamik istekler doğrudan origin sunucuya gider. Bunu dengelemek için stale-while-revalidate ve surrogate key tabanlı cache invalidation teknikleri kullanılır,

DNS düzeyinde Anycast yönlendirme, kullanıcıyı en yakın PoP'a yönlendirir. Ancak Anycast tek başına yeterli değildir. Türkiye'de yaşanan geniş çaplı bir internet kesintisinde, yurt dışı PoP'lara yönlendirme yapılmazsa haber platformu erişilemez hale gelir. Bu yüzden çoklu CDN ve kendi origin failover stratejisi, haber siteleri için kritik bir dayanıklılık katmanıdır.

Haber Başlıklarının Sınıflandırılması: NLP ve Varlık Tanıma

Bir haber platformuna dakikada yüzlerce yeni başlık girer. Bu başlıkların tamamını insan editörlerin tek tek etiketlemesi ekonomik değildir. Otomatik sınıflandırma modelleri, başlıkları siyaset, ekonomi, spor, teknoloji gibi kategorilere ayırır. Bu süreçte geleneksel TF-IDF + lojistik regresyon modellerinden transformer tabanlı modellere kadar geniş bir yelpaze kullanılır. Çok dilli modeller, İngilizce dışındaki haber akışlarında da yüksek doğruluk sağlar.

Varlık tanıma (Named Entity Recognition) ise başlıktan kişi, kurum, yer, tarih ve sayısal değerleri çıkarır. Örneğin "A Haber canlı yayınında açıklanan fon rakamları piyasaları hareketlendirdi" cümlesinde; A Haber kurum, fon finansal kavram, piyasalar ise genel sektör olarak işaretlenir. Bu varlık düğümleri, daha sonra ilgili haber öneri sisteminde kullanılabilir. Kullanıcı daha önce belirli bir kişiyle ilgili haberleri okuduysa, varlık grafiği sayesinde benzer içerikler önerilir.

Burada dikkat edilmesi gereken en önemli mühendislik sorunu, varlık belirsizliğidir (entity disambiguation). "Fon" kelimesi finansal bir araç olabileceği gibi bir ses kaydı veya farklı bir kavram da olabilir. Aynı şekilde "Fatma Betül Sayan" ifadesi sosyal medya kullanıcıları tarafından kısaltılarak yazılabilir. Bilgi grafiği üzerinde alias çözümleme yapmayan bir sistem, bu varyantları ayrı varlıklar olarak değerlendirir ve trend analizi yanlış sonuçlanır.

Veri Gizliliği, Kimlik Yönetimi ve Haber Kişiselleştirme

Kişiselleştirilmiş haber akışları, kullanıcı davranış verilerini işler. Bu veriler; okuma süresi, kaydırma derinliği, tıklanan başlıklar ve bildirim etkileşimleri gibi sinyalleri içerir. Bu sinyallerin toplanması, KVKK ve GDPR gibi düzenlemelere tabidir. Teknik olarak bu, açık rıza yönetimi, veri minimizasyonu ve anonimleştirme gerektirir.

Kimlik yönetimi katmanında OAuth 20 ve OpenID Connect standartları kullanılır. Kullanıcı sosyal medya hesabıyla giriş yaptığında, haber platformu yalnızca gerekli kapsamları (scope) talep etmelidir. Gereksiz scope talebi, hem gizlilik riski hem de kullanıcı güveni kaybıdır. Ayrıca oturum belirteçleri (token) kısa ömürlü olmalı ve refresh token rotasyonu uygulanmalıdır. Bu pratikler, OAuth 20 resmi belgelerinde ayrıntılı biçimde yer alır.

Denver Mobile App Developer olarak, üretim ortamında kişisel verileri analitik depoya yazmadan önce pseudonymization uyguladık. Kullanıcı ID'leri deterministik bir hash fonksiyonuyla maskelendi; ancak hash çözümlemesini önlemek için tuzlama (salting) eklendi. Bu sayede veri analistleri trendleri görebilirken, bireysel kullanıcı kimliği korunmuş oldu.

Felaket Anında Uyarı Sistemleri ve Kritik Bildirim Altyapısı

Deprem, sel veya büyük bir güvenlik olayı sırasında haber platformları, milyonlarca kişiye aynı anda kritik bildirim göndermek zorundadır. Bu tür durumlarda push notification servisleri - Firebase Cloud Messaging (FCM), Apple Push Notification Service (APNs) - tek başına yeterli olmayabilir. Bildirimlerin yanı sıra SMS, e-posta ve hücresel yayın (cell broadcast) gibi yedek kanallar devreye alınır.

Kritik uyarı sistemlerinin temelinde pub/sub mimarisi vardır. Bir uyarı tetiklendiğinde, mesaj kuyruğu aracılığıyla tüm abonelere dağıtılır. Bu dağıtımın sıralı ve idempotent olması gerekir. Aynı bildirimin iki kez gönderilmesi kullanıcıda paniğe yol açabilir; hiç gönderilmemesi ise daha büyük bir sorundur. Bu yüzden bildirim gönderiminde en az bir kez teslimat (at-least-once delivery) ile idempotency anahtarı birlikte kullanılır.

Üretim ortamında, 1 milyon hedefli push bildirimini tek seferde göndermek yerine kademeli (staged) gönderim uyguladık. İlk 10. 000 bildirim gönderildikten sonra teslimat oranı ve sunucu tepkisi izlendi; ardından kalan kullanıcılara dalgalar hâlinde iletildi. Bu yaklaşım, FCM kotasının aşılmasını ve olası throttle limitlerini önledi.

Sıkça Sorulan Sorular

Haber platformları neden düşük gecikmeye ihtiyaç duyar?

Kullanıcılar son dakika haberlerini sosyal medyadan öğrendikten kısa süre sonra platformda görmek ister. Yüksek gecikme, kullanıcı güvenini kaybettirir. Teknik olarak düşük gecikme; Kafka, Redis, LL-HLS ve push notification servislerinin birlikte improve edilmesiyle sağlanır.

A Haber gibi canlı yayın kanallarında hangi protokoller kullanılır?

Canlı yayınlarda en yaygın protokol HLS'dir, and düşük gecikme gereksinimi için LL-HLS tercih edilirKodlama tarafında FFmpeg veya donanım kodlayıcılar, dağıtım tarafında ise CDN ve edge sunucular kullanılır.

Haber doğrulama sistemlerinde makine öğrenmesi nasıl çalışır?

Makine öğrenmesi, başlık ile gövde arasındaki tutarsızlıkları, kaynak güvenilirliğini ve görsel manipülasyonlarını analiz eder. NER modelleri kişi, kurum ve yer bilgilerini çıkarır; bilgi grafiği ile çapraz kontrol yapılır. Nihai yayın kararı genellikle insan editördedir.

Bir haber uygulamasında anlık bildirim altyapısı nasıl kurulur?

Anlık bildirimler için FCM veya APNs kullanılır. Ancak bu servislerin önüne bir mesaj kuyruğu ve yük dengeleyici konur. Gönderimler kademeli yapılır, idempotency anahtarı ile tekrarlar engellenir. Kritik durumlarda SMS ve hücresel yayın yedek kanal olarak devreye girer.

CDN seçimi haber sitesi performansını nasıl etkiler?

CDN, statik içerikleri kullanıcıya en yakın noktadan sunarak gecikmeyi azaltır, and aynı zamanda origin sunucu üzerindeki yükü hafifletirDoğru CDN stratejisi; TTL ayarları, cache invalidation ve çoklu CDN failover içermelidir. Bu unsurlar olmadan yüksek trafikli bir haber sitesi kolayca çökebilir.

Haber altyapısı, göründüğünden çok daha katmanlı bir mühendislik problemidir. Gerçek zamanlı veri hatlarından canlı yayın protokollerine, makine öğrenmesi destekli doğrulamadan kritik bildirim sistemlerine kadar her katman, farklı bir uzmanlık ister. Bu katmanların her biri, kullanıcıya doğru bilgiyi doğru zamanda ulaştırma amacına hizmet eder.

Denver Mobile App Developer olarak, haber ve medya sektörüne yönelik mobil uygulama, API ve altyapı projelerinde bu katmanları uçtan uca tasarlıyoruz. Eğer haber platformunuz için performans, güvenilirlik veya ölçeklenebilirlik konularında bir yol haritasına ihtiyacınız varsa, mobil uygulama geliştirme hizmetlerimiz ve API entegrasyon rehberimiz size yardımcı olabilir. Ayrıca bulut altyapı optimizasyonu üzerine yazdığımız içeriklere göz atabilirsiniz

What do you think

Haber platformlarında hız mı yoksa doğrulama mı öncelikli olmalı? Düşük gecikme hedefleri, yanlış bilgi riskini artırır mı?

WebRTC gibi düşük gecikmeli teknolojiler, milyonlarca izleyicili haber yayınlarında HLS'nin yerini tamamen alabilir mi?

Kişiselleştirilmiş haber akışları, kullanıcıların yalnızca kendi görüşlerini görmesine neden olur mu? Bu teknik bir sorun mu, yoksa ürün tasarımı kararı mı,