Blog / Turnuvalar / İnternetsiz Maçların Kabusu Olmasın: Yerel Ligler İçin Offline‑First Skor Yönetimi ve 5 Dakikada Senkronizasyon Rehberi
İnternetsiz Maçların Kabusu Olmasın: Yerel Ligler İçin Offline‑First Skor Yönetimi ve 5 Dakikada Senkronizasyon Rehberi
Turnuvalar

İnternetsiz Maçların Kabusu Olmasın: Yerel Ligler İçin Offline‑First Skor Yönetimi ve 5 Dakikada Senkronizasyon Rehberi

Giriş

Yerel liglerde maçlar çoğu zaman spor salonlarında, sahalarda veya sınırlı kapsama alanı olan mekanlarda oynanır. İnternet olmadan skoru güvenilir biçimde tutmak, turnuva akışını bozmayacak şekilde merkezi sisteme aktarmak organizatörler için sürekli bir sorun haline gelir. Bu rehberde, offline-first yaklaşımıyla güvenilir skor yönetimi tasarlamanın temel ilkelerini, pratik veri modellerini, çakışma çözümünü ve 5 dakikada senkronizasyon hedefiyle uygulanabilecek somut adımları ele alacağız.

Neden Offline‑First?

Offline-first, önceliği cihaz tarafında çalışmaya veren bir tasarım felsefesidir. Yani uygulama internet yokken de tam işlevsellik sunar; bağlantı geldiğinde ise merkezi sunucuyla veri uyumunu sağlar. Yerel liglerde bunun faydaları açık:

  • Kesintisiz maç yönetimi: Hakemler, saha görevlileri veya mobil skor panelleri internet yokken de veri kaydı yapar.
  • Daha iyi kullanıcı deneyimi: Gecikme ve bağlantı dalgalanmalarına rağmen arayüz anında tepki verir.
  • Veri bütünlüğü: Doğru eşleşme ve sonuç yönetimiyle yanlış sonuçların yayılmasının önüne geçilir.

Temel Tasarım İlkeleri

Başarılı bir offline-first skor sistemi aşağıdaki ilkelere dayanmalı:

  • Yerel yazma yetkisi: Cihazlar, her veri değişikliğini önce lokal veritabanına (transactional) yazar.
  • İzlenebilir değişiklik kaydı: Her işlem için benzersiz ID, zaman damgası ve kullanıcı kimliği saklanır.
  • Detaylı olay temelli kayıt: Sadece son skor tutulmaz; her değişiklik bir olay olarak saklanır. Bu, çakışma çözümünü kolaylaştırır.
  • Güvenli senkronizasyon: Veriler taşıma sırasında şifrelenir ve kimlik doğrulama yapılır.
  • Hız odaklı delta senkronizasyon: Tam veri yerine sadece değişen parçalar transfer edilir; bu 5 dakikada senkronizasyon hedefine katkı sağlar.

Örnek Veri Modeli

Basit ama etkili bir veri yapısı aşağıdaki öğeleri içermelidir:

  • Match: match_id, home_team, away_team, scheduled_time
  • ScoreEvent: event_id, match_id, scorer_id (ya da team_id), points, timestamp, device_id, op_id
  • MatchSummary: match_id, home_score, away_score, last_event_id, last_updated

Her ScoreEvent immutable (değiştirilemez) olmalı. Bir düzeltme gerekiyorsa yeni bir ScoreEvent tipinde 'correction' tipi ekleyin. Bu sayede geçmişin tamamı izlenir ve denetlenebilir.

Senkronizasyon Stratejileri

Hedefimiz, bağlantı geldiğinde 5 dakikada tüm cihazların merkeziyle uyumlu hale gelmesi. Bunu sağlamak için önerilen yaklaşımlar:

1. Delta sync (Değişim bazlı)

Her cihaz, son başarılı senkronizasyon zamanını veya son event_id bilgisini saklar. Sunucuya yalnızca o zamandan sonra oluşan eventler gönderilir. Bu veri boyutunu küçültür ve işlem süresini kısaltır.

2. Olay tabanlı replikasyon

Immutable eventler replikasyon için idealdir. Sunucu ve istemci aynı eventleri idempotent olarak uygular; böylece yeniden gönderim sorun olmaz.

3. Çakışma çözümü (Conflict Resolution)

Çakışma doğrudur: aynı maçta farklı cihazlarda aynı anda bilgi değişebilir. Çözüm yolları:

  • Last writer wins (LWW): En son timestamp sahibi geçerli sayılır. Basit ama bazen yanlış sonuçlar üretebilir.
  • Operational transforms veya CRDT: Daha karmaşık ama deterministik çözüm sağlar. Oyun skorunda, genellikle monoton artan sayılar olduğundan CRDT tercih edilebilir.
  • Domain kuralları ile çözüm: Örneğin; bir gol eventi asla geri alınmaz, sadece correction event eklenir. Hakem onayı olmadan skor düşülmez.

Pratik öneri: immutable event + correction eventi + hakem onayı akışı kombinasyonu, çoğu yerel lig için yeterli ve anlaşılırdır.

5 Dakikada Senkronizasyon Adım Adım

Aşağıdaki işlem akışı saha personeli veya uygulama tarafından otomatik olarak çalıştırılabilir:

  1. Bağlantı algılama: Cihaz internet gördüğünde senkronizasyon süreci tetiklenir.
  2. Auth ve health check: Kısa bir kimlik doğrulama ve sunucudan küçük bir sağlık isteği gönderilir.
  3. Fetch deltas: Sunucuya son_sync_event_id gönderilir, sunucu bu ID sonrası eventleri döner.
  4. Push local events: Cihaz, sunucuya lokal eventleri gönderir; sunucu idempotent olarak bu eventleri uygular ve onay verir.
  5. Conflict detection: Sunucu, aynı match için çakışma tespit ederse domain kurallarına göre çözüm üretir ve sonuçları broadcast eder.
  6. Snapshot güncelleme: Sunucu, match summary snapshotlarını günceller; istemci bu snapshotları alır ve lokal durumu reconcile eder.
  7. Ack & retry: Her başarılı işlem için ack döner; başarısız olanlar geri kalan zaman diliminde retry edilir. Toplam akış 5 dakikanın içinde tamamlanacak şekilde timeout ve yeniden deneme stratejisi tasarlanır.

Pratik ipucu: Her adım çok küçük paketlerde (örneğin 1–2 KB sınırında) yapılırsa mobil bağlantı veya zayıf kapsama alanında bile 5 dakikada tamamlanma ihtimali artar.

Güvenlik ve Veri Bütünlüğü

Yerel lig verileri hassas olmasa da manipülasyon sonuçları turnuva adaletini etkiler. Dikkat edilmesi gerekenler:

  • TLS ile veri transferi
  • JWT veya benzeri token ile kimlik doğrulama
  • İmza: Önemli eventler için cihaz tarafında event imzası kullanın. Bu, hangi cihazın hangi işlemi yaptığını doğrulamaya yardımcı olur.
  • Denetim izi: Tüm eventler ve correctionlar saklanmalı; admin panelinden geriye dönük inceleme mümkün olmalı.

Uygulama Örnekleri ve Araçlar

Offline-first uygulamalar için popüler teknikler ve kütüphaneler vardır. Seçim yaparken lisans, platform (Android, iOS, web) ve ekip yetkinliklerini göz önünde bulundurun:

  • Yerel veritabanları: SQLite, Realm
  • Sync altyapısı/örnekler: PouchDB ile CouchDB replikasyonu, ya da özel REST/GraphQL delta API
  • Gerçek zamanlı yayın: WebSocket veya SSE ile sunucudan snapshot/broadcast

Not: Her teknoloji her senaryoya uymaz. Örneğin küçük amatör liglerde basit event push+pull mantığı yeterli olabilir; büyük liglerde CRDT veya operasyon bazlı yaklaşımlar gerekebilir.

Test, İzleme ve Dağıtım

Her offline-first sistemin test edilmesi şarttır. Öneriler:

  • Kaotik bağlantı testleri: Anlık kopmalar, paket kaybı, geriye yönelik senaryolar çalıştırın.
  • Çakışma simülasyonları: Aynı maçta farklı cihazlardan aynı anda farklı eventler oluşturun ve çözümü izleyin.
  • Performans ölçümü: 5 dakikalık hedefi garanti altına almak için end-to-end testler yapın.

Uygulama Örnek Akışı (Pratik)

Örnek bir saha senaryosu:

  • Hakem maç sırasında skor kaydını tablete yazar. Her gol bir ScoreEvent olarak lokal veritabanına eklendi.
  • Maç bitiminde cihaz interneti görür. Cihaz son_sync_event_id bilgisini sunucuya gönderir.
  • Sunucu kendi eventlerini gönderir, cihaz lokal eventlerini push eder.
  • Sunucu çakışma bulursa match summarysı günceller ve correction gerekiyorsa hem ilgili cihazlara hem de admin paneline bildirim yollar.

Sonuç

Offline-first skor yönetimi, yerel liglerde karşılaşılan en büyük operasyonel sorunlardan birini çözer. Immutable event modeli, delta senkronizasyon, net domain kuralları ve basit çakışma çözüm stratejileriyle 5 dakikalık senkronizasyon hedefi pratikte ulaşılabilir. Önemli olan, sahada görev yapan kullanıcıların işini kolaylaştıran, güvenilir ve denetlenebilir bir akış tasarlamaktır. Bu rehberi adım adım uygulayarak yerel liglerin internetsiz maçlarda kabus yaşamasını engelleyebilirsiniz.

Uygulamayı küçük bir sahada pilotlayın: İlk denemede operasyonel aksaklıklar görünür olur ve sistem gerçek kullanım şartlarında olgunlaşır.