Düşük bağlantı kalitesinin sık görüldüğü sahalarda, turnuvalarda veya mobil uygulamalarda maç kayıtlarını güvenli biçimde tutmak zorunludur. Bu rehberde offline-first yaklaşımla nasıl kayıp olmadan, çakışmaları yöneterek ve hızlı kurtarma süreçleri kurarak sağlam bir sistem inşa edeceğinizi adım adım anlatıyorum.
Neden offline-first? Kısa bir motivasyon
Çevrimdışı veya dalgalı ağ koşulları, veri kaybı, çifte kayıt, oyuncu huzursuzluğu ve güven sorunları yaratır. Offline-first tasarım, önceliği cihaz tarafında veri bütünlüğüne verir: kullanıcılar kesinti sırasında da işlem yapabilir; sistem arka planda senkronize eder. Bu, maç skorları, oyuncu istatistikleri veya maç özetleri için kritik bir gereksinimdir.
Genel mimari bakış: bileşenler
- Yerel depolama: SQLite, Realm, IndexedDB veya dosya tabanlı journal.
- Senkronizasyon motoru: değişiklikleri toplayan, kuyruklayan ve sunucu ile mutabakata sokan bir modül.
- Çatışma çözüm katmanı: otomatik birleştirme (merge), kurallar, veya insan müdahalesi için arayüz.
- İletişim stratejileri: chunked upload, resume, background sync, exponential backoff.
- İzleme & kurtarma: telemetry, replay logları, manuel reconciliation araçları.
5 Adımda uygulanabilir rehber
Adım 1 — Yerel veri modeli ve güvenli yazma (Write-Ahead Log)
Her maç kaydını tek bir immutable giriş (event) olarak düşünün: match_created, score_update, match_ended gibi. Bu eventleri önce cihazda bir Write-Ahead Log (WAL) şeklinde saklayın. WAL faydaları:
- İşlemler sıralı, tekrar oynatılabilir olur (replayable).
- Uygulama çöksede veya bağlantı kaybolsa dahi kayıtlar korunur.
- Senkronizasyon için doğal bir kuyruk sağlar.
Uygulama örneği: bir oyuncunun skoru güncellemesi WAL'a {id: uuid, type: 'score_update', payload: {...}, ts: 2026-02-01T12:34:56Z} şeklinde eklenir. WAL girdilerine durum (pending, syncing, synced, failed) ekleyin.
Adım 2 — Kimliklendirme ve idempotent operasyonlar
Her işlem için client-side UUID kullanın. Sunucu aynı işlemi birden fazla alırsa, idempotency sayesinde tekrar yazmaz. Bu sayede bağlantı tekrar denemelerinde çifte kayıt engellenir.
- UUID (v4) veya zaman tabanlı id (ULID) kullanın.
- Sunucu tarafında gelen id'yi kontrol edip, zaten var ise tekrar uygulamayın.
- Atomic güncellemelerde optimistic locking ile versiyon kontrolü sağlayın.
Adım 3 — Senkronizasyon stratejileri ve çatışma çözümü
Senkronizasyonu tek bir tipte düşünmeyin; karma strateji kullanın:
- Background sync: cihaz ağ geldiğinde arka planda WAL'ı gönderir.
- Push-based: eğer uygulama açık ve ağ stabil ise anlık push ile real-time güncelleme.
- Pull-based: cihaz açıldığında sunucudan son durumu çekip reconcile eder.
Çatışma çözümü (conflict resolution) için üç yaygın yaklaşım:
- Last-write-wins (LWW): basit ama bazı veri kayıplarına yol açabilir.
- Merge kuralları: alan bazlı birleşim örn. skor her zaman maksimumu alır veya oyun içi sequence numarası ile seçim yapılır.
- CRDT/OT (Conflict-free Replicated Data Types / Operational Transform): karmaşık ama otomatik tutarlılık sağlar; metin ve sıra gibi veri tipleri için uygundur.
Maç skoru örneği: iki cihaz farklı skor gönderirse, kural olarak en yüksek toplam skor veya zamana göre daha yeni olan seçilebilir. Kritik senaryolarda insan onayı filtresi ekleyin: otomatik kurallar belirsizse maç yöneticisine yönlendirin.
Adım 4 — Güvenilir transfer: chunking, resume, backoff
Büyük dosyalar (ör. maç videoları, replay dosyaları) için tek parça upload yerine chunked upload kullanın. Her chunk idempotent olmalı ve sıra numarası taşımalıdır.
- Chunk boyutu: 256KB–4MB arası; mobil şartlara göre test edin.
- Resume token: sunucu yüklenen chunk'ları kaydeder; kesinti sonrası cihaz eksik chunk'tan devam eder.
- Retry ve backoff: exponential backoff + jitter uygulayın; sunucu 429 veya 5xx dönerse uygun bekleme.
Ayrıca, kayıt gönderimi başarısız olursa kademeli degradasyon uygulayın: öncelikli küçük meta-veri (ilk skor, player IDs, timestamps) önce gönderilsin; büyük medya dosyaları arkaya alınsın.
Adım 5 — İzleme, recovery playbook ve manuel reconciliation
Her sağlam sistemin iyi tanımlanmış bir kurtarma süreci olmalı:
- Telemetri: sync success/fail oranları, ortalama gecikme, tekrar sayısı, en sık hata kodları.
- Replay log: WAL tabanlı replay ile sunucu tarafında işlemler tekrar oynatılabilir.
- Manual reconciliation: tutarsızlık durumunda yöneticinin görebileceği bir UI; farklı kaynaklardan gelen verileri karşılaştırma ve birleştirme araçları.
Hızlı kurtarma playbook örneği:
- Sorunu tespit et (monitoring alert).
- İlgili cihazların WAL girdilerini topla (kullanıcı desteğiyle veya merkezi logdan).
- Sunucuda replay çalıştır; idempotency kontrolleriyle tekrar uygula.
- Tutarsızsa otomatik merge kurallarını uygula; kritik veri ise insan müdahalesine yönlendir.
- Çözüm sonrası kullanıcıya durum bildirimi gönder ve sistemi stabilize et.
Pratik örnek: Mobil maç skoru uygulaması akışı
Senaryo: Hakem saha içinde skoru güncelliyor ama bağlantı zayıf. Akış şu olmalı:
- Hakemin yaptığı her güncelleme WAL'a eklenir (pending).
- Uygulama kullanıcıya Kaydedildi — çevrimdışı benzeri bir bildirim gösterir.
- Ağ geri geldiğinde arka plan sync başlar; sunucuya requests sıralı gönderilir.
- Sunucu idempotency sayesinde duplicate işlemleri reddeder; geri dönüşte güncel maç durumu client'a iletilir.
- Herhangi bir çakışma varsa uygulama sahneye göre (ör. skor tutarsızlığı) otomatik kurallarla veya yönetici müdahalesiyle düzeltilir.
Test ve üretime alma stratejileri
Gerçek dünyada test çok önemlidir. Öneriler:
- Simüle edilmiş ağ koşulları: packet loss, yüksek latency, bağlantı kopma senaryoları.
- Kaos testi: bilinçli başarısızlıklar ile sistem davranışını gözlemleyin.
- A/B testleri: farklı çatışma çözüm politikalarını gerçek kullanıcılarda test edin.
- Geri bildirim döngüsü: saha personelinden alınan içgörüler ile kuralları güncelleyin.
Güvenlik ve uyumluluk
Maç kayıtları kişisel veri veya telif hakkı içerebilir. Temel kurallar:
- Yerel veriyi şifreleyin (at-rest) ve taşıma sırasında TLS kullanın.
- Yetkilendirme: her eventin kullanıcı cihazı ile eşleştiğinden emin olun.
- Audit log: kim/ne/nerede değişiklik yaptı kayıtları saklanmalı.
Kontrol listesi: Uygulamaya almak için
- WAL ile yerel kayıt ve durum yönetimi (pending/sync/failed) kuruldu mu?
- Her işlem için benzersiz id ve idempotency mevcut mu?
- Senkronizasyon motoru backoff, resume ve chunking destekliyor mu?
- Çatışma çözümü kuralları ve insan müdahalesi mekanizması tanımlandı mı?
- Monitoring, replay log ve recovery playbook hazır mı?
Sonuç
Offline-first yaklaşım maç kayıtlarını korumak ve kullanıcı güvenini sağlamak için bugün en sağlam yöntemdir. Bu rehberde sunduğum beş adım — yerel WAL, idempotency, esnek senkronizasyon, güvenilir transfer ve kapsamlı kurtarma planı — pratikte uygulanabilir bir çerçeve sunar. Uygulama sürecinde küçük prototiplerle başlayıp gerçek saha testleriyle kuralları iyileştirin; karmaşık çatışma durumlarında otomatik çözümler yerine insan denetimini bir seçenek olarak bırakın.
Özet: Cihaz tarafında güvenilir kayıt, sunucu tarafında idempotency ve iyi tanımlanmış bir recovery süreci kombinasyonu, düşük internet koşullarında bile maç verilerini kaybetmeden yönetmenizi sağlar.
Uygulama ipucu: İlk canlı lansmanda, kritik maçlar için "kırmızı yol" (manual oversight) uygulayın; sistem stabil hale geldikçe otomasyon seviyesini artırın.
