Canlı bahiste gecikme gerçekten ne demek

'50ms altı oran gecikmesi' dediğimizde belirli bir sayıyı kastediyoruz: kaynak feed'in (Betradar, Genius Sports, BetGenius) güncellenmiş bir fiyatı agregatörümüze yayınladığı an ile o fiyatın bir oyuncunun açık WebSocket bağlantısında render edildiği an arasındaki p50 duvar saati zamanı.

Sporbet Soft üretim sayısı 47ms p50, 180ms p99'dur — 30 günlük yuvarlanan pencere boyunca tüm partnerler için ölçülür. 180ms kuyruk, keskin bir bahisçinin platformu ayrı bir canlı veri feed'ine karşı güvenilir şekilde arbitraj edemeyeceği anlamına gelir.

Gecikmeye öncelik verme mantığı entegrasyon anatomisi yazımızdadır.

Redis pub/sub fan-out ve bölümlenmiş abonelikler

İlk alt sistem fan-out katmanıdır. Güncellenmiş bir fiyat olayı agregatörümüze indiğinde, bir Redis pub/sub topic'ine yeniden yayınlanır. Topic anahtarı yapılandırılmıştır: odds:{sport_id}:{league_id}:{market_id}. Granularite seçimi önemlidir. Çok kaba — tek bir odds topic'i — her abone her olayı alır ve ağı ezer.

Sporbet Soft'un bölüm stratejisi top-100 ligler için market seviyesi, uzun kuyruk için lig seviyesidir. Bir Premier League maçının maç sonucu marketine abone olan bir oyuncu tek bir topic'e abone olur ve yalnızca o market için tek bir fiyat güncellemesi akışı alır.

Redis burada doğru araçtır çünkü fan-out hop için gecikme bütçesi 5ms'nin altındadır. Tek bir Champions League maç haftası fan-out üzerinden 800K olay/dakika iter. Redis cluster bunu milisaniye altı p99 yayın gecikmesiyle sürdürür.

Sticky-session WebSocket ve bağlantı state machine

İkinci alt sistem WebSocket filosudur. Her oyuncu oturumu edge gateway'lerimizden birine tek bir uzun ömürlü WebSocket bağlantısı açar. Bağlantı sticky'dir — yani bir oturum çerezi üzerinde tutarlı hash ile Katman-4 yük dengeleyici tarafından yönlendirilir.

Bağlantı state machine'i her bağlantının abone olduğu topic'leri, oyuncunun kimliği doğrulanmış oturumunu, back-pressure su işaretini ve son onaylanan olay ID'sini tutar. Yeniden bağlantıda — mobil ağlarda yaygın — istemci son onaylanan olay ID'sinden devam eder ve sunucu kaçırılan olayları halka tamponundan replay eder.

Aynı idempotency deseni settlement motorumuzun kısmi cashout için kullandığı burada görünür.

Edge-cached statik shell ve time-to-interactive bütçesi

Mevcut bir bağlantı için gecikme bir şeydir. İlk paint için gecikme — oyuncunun iframe'e girmesi ile taze oranları görmesi arasındaki süre — başka bir şeydir. Sporbet Soft, iframe'in statik shell'ini edge-cache ederek mobilde 1.5s altı time-to-interactive vurur.

Shell küçük bir HTML belgesidir (50KB altı, yaklaşık 14KB'ye gzipli) artı 200KB altı bir JavaScript bundle. Her ikisi de agresif cache header'ları ile bir CDN'den (bizim için Cloudflare) sunulur.

Tüm dizi Google'ın 200ms INP eşiğini marjla geçecek şekilde ayarlanmıştır — bu performans bütçesinin sabit ücrete nasıl katlandığı için bkz. sportsbook fiyatlandırma.

Back-pressure koruması: yukarı akışta bir feed patladığında ne olur

Canlı oran trafiği düzgün değildir. El Clasico'da uzatma zamanında bir kırmızı kart, maçın her marketi yeniden fiyatlandığında 30 saniyelik bir pencerede fiyat olaylarında 50x'lik bir sıçramaya neden olur. Back-pressure koruması olmayan bir platform bu olayların WebSocket gönderme tamponunda sıraya girdiğini görür ve sonunda gateway dosya tanımlayıcıları biter ve düşer.

Sporbet Soft gateway'leri açık back-pressure'ı iki mekanizma ile uygular. İlki, bağlantı başına gönderme tampon yüksek-su işaretleri. İkincisi, filo genelinde devre kesicileri.

Kritik olarak, back-pressure asla gateway'in eski oranları kabul etmesine neden olmaz. Bütünlük invariantı — her bağlantı her market için monoton-azalmayan bir olay dizisi görür — tüm koşullar altında geçerlidir.

Çoklu bölge active-active ve saniye altı failover

Son alt sistem failover topolojisidir. Sporbet Soft üç bölgeyi — EU-West, EU-Central, Middle-East — active-active konfigürasyonda çalıştırır. Her bölgenin WebSocket filosu, Redis cluster'ı, agregatörü ve settlement motorunun tam bir kopyası vardır.

DNS tabanlı geo-yönlendirme her oyuncuyu en yakın bölgesine gönderir. Bir bölge bozulduğunda, DNS katmanı yeni bağlantıları 30-60 saniye içinde bir sonraki en yakın bölgeye yeniden yönlendirir. Uçtan uca failover bir saniyenin altında kullanıcı görünür kesintidir.

Active-active model ayrıca sıfır kesinti dağıtımlarını sağlar. Iframe üzerindeki operatörler — bkz. B2B sportsbook iframe — asla bir bakım penceresi görmezler.

Neden API polling sizi oraya götürmez

Salt API entegrasyonlarını değerlendiren operatörler bazen yüksek frekansta bir REST oran endpoint'ini polling ederek benzer gecikmeyi vurup vuramayacaklarını sorarlar. Cevap hayır. 100ms poll aralığı en kötü durumda 100ms tazelik boşluğu verir ve vendor'un REST endpoint'inde request bütçesini eşzamanlı kullanıcılarla doğrusal olarak yakar.

Push tabanlı WebSocket fan-out diğer yöne ölçeklenir: vendor abone sayısından bağımsız olarak market güncellemesi başına bir olay gönderir. Tazelik boşluğu poll aralığı ile değil ağ gecikmesi ile sınırlıdır.

Salt API build değerlendiriyorsanız, canlı bahis gecikme bütçesi tek başına genellikle kararı iframe'e itecek kadar yeterlidir — tam TCO için iframe vs API karşılaştırmamıza bakın.