Offline-first mobil uygulama: senkronizasyon ve çakışma tasarımı

Kimler için?

Ağ kesintilerinde çalışan Flutter, React Native, iOS ve Android uygulamaları geliştiren ekipler.

Başlamadan önce

Yerel veritabanı, kullanıcı oturumu ve backend’de değişiklik sürümü tutabilen bir veri modeli.

1. Offline kapsamını işlem bazında seçin

Not yazmak çevrimdışıyken yapılabilir; ödeme onayı veya sınırlı stok tüketimi genellikle sunucunun son kararını gerektirir. Her buton için “yerelde kabul edildi” ile “sunucuda kesinleşti” durumunu ayırın. Ekranda bekleyen işlemi açık gösterin. Kullanıcı uygulamayı kapatsa bile veri kaybolmamalı; yalnızca bellekte duran bir liste gerçek offline kuyruk değildir.

2. Kalıcı bir outbox tasarlayın

Yerel kaydı ve gönderilecek işlemi aynı yerel transaction içinde saklayın. İşleme benzersiz bir operation_id verin. Sunucu bu kimlikle aynı eylemin daha önce tamamlanıp tamamlanmadığını kontrol etmelidir. Bir timeout cevabın kaybolduğunu gösterebilir; işin yapılmadığını kanıtlamaz. Kimliği her yeniden denemede değiştirmek tekrar etkisini engellemez.

operation_id | entity_id | base_version | payload | state
abc-123      | note-42   | 7            | {...}   | pending
State: pending → sending → acknowledged / conflict

3. Çakışma politikasını ürün sahibiyle belirleyin

İki cihaz aynı notu değiştirdiğinde sadece son saat damgasına bakmak kullanıcının yazısını silebilir. Cihaz saatleri de farklı olabilir. Basit bir sürüm numarası ile sunucu daha eski tabana dayanan değişikliği reddedebilir. Metin birleştirme, kullanıcı seçimi veya alan bazlı politika ayrı tasarım kararlarıdır; tek bir “son yazan kazanır” kuralını her kayıt türüne uygulamayın.

4. Silme ve oturum değişimini unutmayın

Silinen kayıt için bir tombstone veya değişiklik günlüğü gereklidir; aksi halde offline cihaz kaydı yeniden oluşturabilir. Kullanıcı çıkış yaptığında kuyruktaki işlemlerin hangi hesaba ait olduğunu kontrol edin. Hesap A’nın bekleyen değişiklikleri hesap B’nin oturumuyla gönderilmemelidir. Yerel hassas veriyi temizleme politikası ile bekleyen işleri kurtarma beklentisini birlikte belirleyin.

5. Zayıf ağ senaryolarıyla test edin

İstek gönderdikten sonra bağlantıyı kesin, yanıt gelmeden uygulamayı kapatın, iki cihazı farklı sırayla çevrimiçi yapın ve aynı kaydı bir cihazda silin. Sunucuda tekrar kayıt, yetki hatası ve kayıp değişiklik oluşmamalıdır. Sınırlı geri çekilme ve jitter kullanın; tüm cihazların aynı anda tekrar denemesi yoğunluk oluşturur.

• Aynı operation_id için iş etkisi bir kez oluşmalı.
• Çakışma sessizce başarılı olarak işaretlenmemeli.
• Kuyruk boyutu ve en eski bekleyen iş ölçülmeli.
• Kullanıcıya tekrar deneme ve çakışma çözüm seçenekleri sunulmalı.