Canlı Bahis Altyapısı Gereksinimleri: Teknik Kılavuz

Canlı (in-play) bahis, maç sürerken oranların sürekli değiştiği ve oyuncunun saniyeler içinde karar verdiği bir üründür. Bu hız, maç öncesi bahiste pek hissedilmeyen teknik gereksinimleri öne çıkarır: verinin gecikmeden gelmesi, oranların doğru anda güncellenmesi, riskli anlarda marketlerin askıya alınması ve maç bitince bahislerin hızla sonuçlandırılması. Bu rehberde canlı bahis altyapısının ana bileşenlerini ve sağlayıcı değerlendirirken sorman gereken soruları ele alıyoruz.

Canlı bahisi farklı kılan ne?

Maç öncesi bahiste oranlar uzun süre görece sabit kalır ve sistem daha çok okuma yükü taşır. Canlı bahiste ise her gol, kart ya da tehlikeli atak oranları değiştirir. Oyuncu ile operatör arasında bir bilgi yarışı vardır: sahadaki olaydan önce haberdar olan taraf avantajlıdır. Altyapının görevi, bu yarışta operatörü korurken oyuncuya akıcı bir deneyim sunmaktır. Ayrıca oyuncu, ekranda gördüğü oranla sistemin kabul ettiği oranın tutarlı olduğuna güvenmek ister; bu güven bir kez sarsıldığında geri kazanmak zordur.

Temel bileşenler

Veri akışı (feed)

Maç olayları ve skor bilgisi, veri sağlayıcılarından sürekli bir akış olarak gelir. Betradar gibi isimler bu alanın bilinen sağlayıcılarıdır. Akışın gecikmesi, eksik gelmesi ya da tamamen kesilmesi, üzerine kurulu her şeyi etkiler.

Oran motoru ve market askıya alma

Oran motoru gelen olaylara göre fiyatları yeniden hesaplar. Gol, penaltı ya da belirsiz bir an gibi durumlarda marketlerin anında askıya alınması gerekir; aksi halde olayın sonucunu önceden bilen oyuncular eski oranlardan bahis yapabilir.

Bahis kabul gecikmesi

Canlı bahiste kupon onaylanmadan önce kısa bir bekleme uygulanması yaygın bir korumadır. Bu sürede oran değişir ya da market askıya alınırsa bahis reddedilir veya oyuncuya yeni oran önerilir. Gecikmenin uzunluğu, risk ile oyuncu deneyimi arasında kurulan bir dengedir.

Gerçek zamanlı iletim

Oran değişikliklerinin tarayıcıya ya da uygulamaya anında ulaşması için sürekli açık bağlantılar kullanılır; WebSocket ve Server-Sent Events bu işin yaygın yöntemleridir. Asıl zorluk, büyük maçlarda aynı anda açık kalan bağlantı sayısının kısa sürede hızla artmasıdır.

Settlement

Maç ya da market kapandığında bahislerin sonuçlandırılıp bakiyelere yansıması gerekir. Büyük bir maçın sonunda çok sayıda kupon aynı anda sonuçlanır; bu anda veritabanı ve kuyruk sistemleri en yoğun yükü taşır.

Gecikme bütçesini düşünmek

Canlı bahiste toplam gecikme tek bir yerden gelmez: veri sağlayıcısından platforma, oran motorundan iletim katmanına, oradan oyuncunun cihazına kadar her adım bir miktar süre ekler. Mobil ağlar bu zincire değişken bir halka daha ekler. Sağlayıcıyla konuşurken tek bir “gecikme” rakamı istemek yerine her adımın nasıl ölçüldüğünü ve nasıl izlendiğini sormak çok daha sağlıklı bir resim verir.

Büyük maç anında yük nereye biner?

• Giriş ve oturum: Maç başlamadan hemen önce çok sayıda oyuncu aynı anda giriş yapar.
• Bağlantı sayısı: Canlı oran ekranını açık tutan her oyuncu sürekli açık bir bağlantı demektir.
• Kupon trafiği: Kritik anlarda, örneğin bir golün hemen ardından, kupon gönderimi yoğunlaşır.
• Settlement: Maç biter bitmez sonuçlanan kuponlar veritabanına ani bir yazma yükü bindirir.
• Para çekme talepleri: Kazanan kuponların ardından çekim talepleri artar ve ödeme entegrasyonları yoğunlaşır.

Bu anların her biri farklı bir katmanı zorlar. Bu yüzden kapasite planlaması tek bir “eşzamanlı kullanıcı” rakamıyla değil, akış bazında yapılmalıdır.

Dayanıklılık: bir şey ters giderse

• Feed kesilirse: Etkilenen marketler güvenli şekilde askıya alınmalı, akış geri geldiğinde kontrollü biçimde açılmalıdır.
• İletim katmanı zorlanırsa: Bağlantılar düştüğünde istemci kendiliğinden yeniden bağlanmalı ve kaçırdığı güncellemeleri almalıdır.
• Settlement gecikirse: Oyuncuya bahsinin sonuçlanmayı beklediği açıkça gösterilmelidir.
• Site erişilemez olursa: Açık kuponu olan oyuncular için durum hızla duyurulmalı, destek ekibi hazır bekletilmelidir.

Sağlayıcıya sorulacak sorular

1. Hangi veri sağlayıcılarıyla çalışıyorsunuz ve bir feed kesildiğinde yedek plan nedir?
2. Market askıya alma kuralları operatör tarafından ayarlanabiliyor mu?
3. Canlı bahis kabul gecikmesi spor ve market bazında değiştirilebiliyor mu?
4. Büyük etkinliklerden önce kapasite planlaması için ne tür bir koordinasyon sunuyorsunuz?
5. Planlı bakımları ne kadar önceden ve hangi kanaldan duyuruyorsunuz?

Kapasite tarafını önceden sınamak için yük testi rehberimize de göz atabilirsin.

Etkinlik günü operasyon tarafında izleme

Canlı bahis kalitesinin büyük kısmı sağlayıcının elindedir; sitenin açık ve hızlı olup olmadığını izlemek ise senin elindedir. LLCBullet'te site kontrolü görevi, seçtiğin sitelerin erişilebilirliğini ve yanıt süresini kaydeder. Oran gecikmesini ya da feed kalitesini ölçmez; odak noktası sitelerin ulaşılabilir olmasıdır. Yoğun maç akşamlarını kapsayan bir zamanlama örneği:

# Cuma, cumartesi ve pazar 17:00-23:59 arasında her 5 dakikada bir
*/5 17-23 * * 5,6,0

Görevler en fazla 5 dakikada bir çalışabilir ve ifade seçtiğin saat dilimine göre yorumlanır. Farklı senaryolar için cron örnekleri yazımıza bakabilirsin.

Sonuç

Canlı bahis altyapısı; veri akışı, oran motoru, iletim ve settlement katmanlarının birlikte ve kesintisiz çalışmasını gerektirir. Sağlayıcını bu katmanların her biri için somut sorularla değerlendir, etkinlik günlerinde ise sitelerinin erişilebilirliğini düzenli kontrol ederek sorunları erken yakala. Kendi tarafında kontrol edebileceğin şeyleri, yani sitelerin erişilebilirliğini, bildirim kanallarını ve destek hazırlığını etkinlik öncesinde gözden geçirmek, sağlayıcı tarafındaki sürprizlerin etkisini de azaltır.