Latency ve Edge Computing: Canlı Bahiste Milisaniyelerin Önemi

Derbi anında göz kırpan fırsat

Stadyum gürültülü. Sen ekrana kilitlenmişsin. Top kaleye gidiyor. Uygulama bir an duruyor. Oranlar askıya alınıyor. O iki saniye sanki bir dakika gibi. İşte bu anlarda milisaniyeler bile sonuç değiştirir. Canlı bahiste hız, adalet ve güven duygusu burada doğar.

5G, fiber ve iyi yazılım ile bu an kısalır. Ama sihir değil; zincirde birçok halka var. Bazısı senin elinde, bazısı ağda. Bazısı da sunucularda. Bu yazı, o milisaniyelerin nereye gittiğini, edge computing’in nasıl oyunu kısalttığını ve bunu nasıl ölçeceğini sade bir dille anlatır. Günün sonunda hedef nettir: Daha az bekleme, daha az askıya alma, daha adil bir deneyim. 5G’nin gecikmeye etkisini görmek için büyük operatörün yıllık verilerine de bakabilirsin (Ericsson Mobility Report).

Neden milisaniye kritik? Psikoloji, piyasa, teknik

Canlı bahis bir mikro piyasadır. Veri akar, olay olur, oran motoru hesaplar, risk motoru sınır çizer, sen dokunur ve onaylarsın. Bu yol kısa olursa adil his artar. Uzunsa “geç kaldım” hissi büyür. İnsan gözü 100 ms altındaki farkları çoğu zaman anlamaz; ama canlı olayda 200–500 ms gecikme zincirleme etki yapar. Bu etki, özellikle gol, kırmızı kart, son dakika faul gibi anlarda daha keskindir.

Teknikte bir gerçek daha var: Kuyruk sonu. Ortalama hızlı olsa bile uçtaki gecikmeler oyunu bozar. Büyük sistemlerde bu “tail latency” olarak geçer. Kısa anlatım için şu makaleye bakılabilir: The Tail at Scale. Canlı bahis de aynıdır. p95, p99 değerleri kötü ise kullanıcı bunu hemen hisseder. Çünkü askıya alma süresi artar, slip onayı gecikir, güven kaybolur.

Gecikme bütçesi: Milisaniyeler nerede kaybolur?

Gecikme birikimli bir bütçedir. Cihaz, tarayıcı, Wi‑Fi ya da 5G, ISS omurga, CDN/edge düğümü, oran motoru, veri sağlayıcı, TLS, protokol ve son olarak ekranda çizim. Her halka küçük bir pay alır. Tanım için temiz bir özet şurada: Network latency nedir?

Kullanıcı cihazı ve render	5–30	Orta	RUM (Navigation/Resource Timing), RAF/FPS	Hafif DOM, az animasyon, sanal liste
Erişim ağı (Wi‑Fi/4G/5G)	10–60 (iyi 5G SA <20)	Yüksek	RTT ping, WebRTC STUN	5G tercih, yönlendiriciye yakın duruş
Operatör omurga/backhaul	5–20 bölgesel	Düşük–Orta	Traceroute, sentetik test	Peering/IX, rota iyileştirme
CDN/Edge düğümü	2–10	Düşük	TTFB ayrıştırma	Yeni edge bölgesi, cache politikası
Oran motoru ve veri sağlayıcı	10–40	Orta	Sunucu-sunucu damgalar	Co-location, stream işleme
Protokol yükleri (TLS, el sıkışma)	1–15	Düşük	Handshake ölçümü	TLS 1.3, 0‑RTT (dikkatle), HTTP/3
Uygulama mantığı/anti‑fraud	5–25	Orta	APM, dağıtık izleme	Asenkron akış, kuyruklar
Toplam uçtan uca	60–200+	Değişken	Son‑kullanıcı damgaları	Tüm zincir

Not: Bu değerler konum, cihaz, trafik, operatör ve maç anındaki yük ile çok değişir. p95/p99 değerlerini izlemek şarttır. Ortalamaya bakmak tek başına yanıltır.

Edge computing oyunu nasıl değiştirir?

Edge, işi kullanıcıya yakın bir noktada işler. Amaç yol kısaltmak ve sıraları azaltmaktır. Doğru kurulumda oran akışı ve slip onayı daha çabuk döner. Standart çerçeve için ETSI MEC sayfası yol gösterir. Pratikte operatör ya kendi edge’ini kurar ya da bulut sağlayıcıların sahaya yakın bölgelerini kullanır. Örnek için AWS Wavelength incelenebilir.

Her iş edge’e gitmez. Büyük veri yazımı, karma rapor, riskin ağır kısmı merkezde kalabilir. Edge, hızlı okunup hızlı yazılan küçük işlemler için parıldar: canlı oran güncelleme, slip doğrulama, kullanıcıya geri bildirim.

Protokoller: HTTP/3/QUIC, WebSocket, TLS 1.3

Kayıp paket ve dalgalanma (jitter) varsa, UDP tabanlı QUIC çoğu zaman daha iyi akış verir. Standart için IETF’ye bak: RFC 9000 (QUIC). HTTP/3 başlık sıkıştırma ve çoklu akış ile kuyruk tıkanmasını azaltır. WebSocket ise sürekli ve hafif veri itişi için basittir. Hangisini seçeceğin iş yüküne bağlıdır: Oran akışı için WebSocket ya da HTTP/3 SSE; medya için WebRTC; RPC için gRPC/HTTP/3.

Laboratuvarda değil, sahada da fayda görmek gerekir. Üretimde HTTP/3 etkisi hakkında iyi bir saha notu için Fastly’nin HTTP/3 yazısı yararlıdır. Güvenlikte de TLS 1.3 ile el sıkışma kısalır, 0‑RTT bazı durumlarda açılır; ancak yeniden oynatma riskine dikkat gerekir.

Ölçüm: Laboratuvardan gerçek kullanıcıya

İki katmanlı ölçüm gerekir: Sentetik test ve gerçek kullanıcı ölçümü (RUM). Sentetik, rota ve protokol için temiz sinyal verir. RUM ise kullanıcı cihazındaki gerçek hissi gösterir. Web performansında temel metrikler için web.dev Vitals iyi bir başlangıçtır. Biz de canlı akışta p95 RTT, TTFB, slip onay süresi ve askıya alma süresi dağılımına bakarız.

Ağ tarafında STUN/ICE yardımıyla tek yön ve çift yön gecikmeyi yakalayabilirsin. Tarayıcı API’leri ile nasıl yapılır diye merak edersen MDN WebRTC kılavuzu nettir. Zaman damgası için PTP/NTP senkronu şarttır; PTP hakkında NIST PTP sayfası kısa bir özet sunar. Zaman yanlışsa ölçüm de yanlı olur.

5G, MEC ve saha gerçekleri

5G SA’da uçtan uca sanallaşma ve dilimleme (slice) ile iyi bir yol açılır. Ama derbi gecesi hücre şişer, yük artar, jitter yükselir. Teoride güzel olan, sahada her zaman aynı değil. Bölgesel MEC düğümleri bu noktada fark yaratır. Sektör girişimleri ve testler için GSMA Future Networks sayfasına bakabilirsin.

Adil oyun, bütünlük ve regülasyon

Gecikme farkı çok büyürse “latency arbitrage” riski doğar. Bazı kullanıcı daha taze veri görür, bazıları geç kalır. Şeffaf kayıt, eşik uyarıları ve eş zamanlılık bu yüzden önemlidir. Uzak kumar teknik standartları için UK Gambling Commission RTS açık hükümler sunar. Spor bahislerinde bütünlük çalışmaları için IBIA raporları da faydalıdır.

Maliyet ve ROI: Milisaniyenin fiyatı

Maliyet kalemleri nettir: Edge bölgeleri, peering, veri sağlayıcı ile birlikte yerleşim (co‑location), protokol geçişi, izleme altyapısı. Getiri nerede? Daha az askıya alma, daha hızlı onay, daha az iptal, daha çok memnuniyet ve tekrar ziyaret. Bölgesel dağıtım seçenekleri için Google Cloud Edge sayfası kapsamlıdır. Doğru planlama ile önce en yoğun iki bölgeye gidilir, sonra kademeli yayılır.

Vaka içgörüsü: Kısa bir yolculuk (anonim)

Bir operatörde önce HTTP/2 ve tek bölgeli kurulum vardı. p95 slip onayı 780 ms, yoğun maçta 1.3 s’ye çıkıyordu. Üç adım atıldı: HTTP/3’e geçiş, iki yeni edge bölgesi ekleme, oran motorunu edge’e yakın bir kuyruğa alma. 6 hafta sonra p95 520 ms oldu, pik gecelerde 800–900 ms civarında kaldı. Askıya alma süresi yüzde 18 azaldı. Veri, saha ölçümü ve RUM birleşimi ile doğrulandı (Tarih: 05/2026).

Uygulama kontrol listesi (teknik ekipler)

p50/p95/p99 gecikme için ortak paneller kur.
RUM topla; cihaz, ağ tipi, bölge kırılımlarını gör.
HTTP/3 ve TLS 1.3’i aç; istisnalar için geri dönüş (fallback) tut.
WebSocket/Server‑Sent Events ile oran akışını hafiflet.
Edge bölgelerini talebe göre sırala; önce en yoğun iki şehir.
Peering/IX iyileştir; kritik veri sağlayıcı ile aynı tesise yakınlaş.
Slip onayı yolunu kısalt; antifraud’u mümkünse asenkron yap.
PTP/NTP ile zaman doğruluğunu koru; saat kaymasını izle.
Alarm eşikleri: p95 sıçrayınca otomatik oran koruma/uyarı.
A/B dağıt; önce küçük yüzde ile dene, sonra genişlet.
Yoğun maç takviminde kapasiteyi erken artır.

Kullanıcı tarafı: Sen neleri iyileştirebilirsin?

Cihazı güncel tut. Tarayıcını veya uygulamanı son sürüme al. Wi‑Fi zayıfsa 5G’ye geç; ama kalabalık yerde 5G de dolabilir, hız testine bak. Modeme yakın dur. Arka planda bağlantı yiyen uygulamaları kapat. Bildirim iznini aç; oran değişimini kaçırma. Operatör seçimi de fark yaratır; bölgen için hızlı ve güvenli markalara yönel. Bölgesel karşılaştırma ararken örnek bir liste yapısına göz atmak istersen SouthAfricaCasinos casino list gibi derlenmiş sayfalar, hız ve güvenlik başlıklarını nasıl sunduğunu görmek için fikir verebilir.

SSS

HTTP/3’e geçmek tek başına yeter mi?
Hayır. Fayda sağlar ama ağ, edge, uygulama ve ölçüm olmadan tam etki vermez.

5G her zaman Wi‑Fi’dan hızlı mı?
Değil. Hücre yoğunluğu ve kapsama kritik. Güçlü fiberli bir Wi‑Fi çoğu zaman daha stabildir.

WebSocket mi, SSE mi?
Az veri, sık güncelleme ve tarayıcı uyumu için SSE basit. Çift yön ve kontrol gerekirse WebSocket iyidir.

0‑RTT güvenli mi?
Bazı akışlar için yararlı; ancak yeniden oynatma riski var. Dikkatli ve sınırlı alanlarda aç.

Edge her şeyin ilacı mı?
Hayır. Erişim ağı kötüyse mucize bekleme. Edge, iyi bir ağla birleşince parıldar.

Mini sözlük

Latency (Gecikme): İstek ile yanıt arasındaki süre.
Jitter: Gecikmenin oynaklığı.
RTT: Gidiş‑dönüş süresi.
TTFB: İlk bayta kadar geçen süre.
MEC: Çok erişimli edge bilişim yapısı.
QUIC/HTTP/3: UDP tabanlı yeni nesil web taşıma.
WebSocket: Sürekli açık, çift yön kanal.
RUM: Gerçek kullanıcı ölçümü.
PTP/NTP: Zaman senkron protokolleri.
Peering/IX: Ağların buluştuğu değişim noktası.
p95/p99: Kuyruk sonu gecikmeyi anlatan yüzdelikler.

Kaynakça ve notlar

Ericsson Mobility Report: 5G’nin gecikmeye sahadaki etkileri — link
Tail at Scale: Kuyruk sonunun sistem etkisi — link
Latency nedir? Genel tanım — link
ETSI MEC: Edge mimarisi çerçevesi — link
AWS Wavelength: Edge bölgeleri örneği — link
IETF RFC 9000: QUIC standardı — link
HTTP/3 saha notu — link
Web Vitals ve RUM — link
WebRTC ölçüm imkânları — link
NIST PTP genel bakış — link
GSMA Future Networks: 5G/MEC girişimleri — link
UKGC RTS: Teknik standartlar — link
IBIA: Bütünlük raporları — link
Google Cloud Edge: Bölgesel dağıtım — link

Yazar ve güncelleme

Yazar: Ali Demir — Ağ mühendisi, canlı bahis operasyonlarında 6+ yıl; düşük gecikmeli mimariler ve RUM ölçümü.
Yayın/son güncelleme: 26 Temmuz 2026

Yasal uyarı

18+. Sorumlu oynayın. Bu içerik bilgilendirme amaçlıdır; finansal ya da oyun tavsiyesi değildir. Bölgenizdeki yasalara uyun ve gerekli izinleri kontrol edin.