Offline Queue: ilkeler, stratejiler ve çalışma mekanizmaları

Çevrimdışı kuyruk nedir?

Offline Queue, cihazın ağ erişimi olmadığında uygulamanın yerel olarak kaydettiği işlemlerin (oluşturma, güncelleme, silme) sıralı bir koleksiyonudur. Bağlantı yeniden sağlandığında, kuyruk işlemleri kullanıcının gerçekleştirdiği sırayla sunucuya gönderir.

Bir senaryo hayal edin: bir mesajlaşma kullanıcısı internetsiz metroda mesaj yazıyor. Her “Gönder” dokunuşu Offline Queue'ya eklenir. Tren tünelden çıktığında ve ağ kullanılabilir olduğunda, tüm mesajlar otomatik olarak gönderilir. Kullanıcı deneyimi — kesintisiz: göndermedeki hafif bir gecikme dışında çevrimdışı olduğunu fark etmez.

Uber Engineering (2024)'e göre, çevrimdışı kuyrukları düşük bağlantı kalitesine sahip bölgelerde günde 2 milyondan fazla işlem işler. Kuyruk, FIFO sırası ve exactly-once garantili teslimat mekanizması ile Room yerel depolamasını kullanır.

data class QueuedOperation(
    val id: String,
    val type: OperationType,
    val endpoint: String,
    val payload: String,
    val timestamp: Long,
    val retryCount: Int = 0,
    val idempotencyKey: String
)

Her işlem, yeniden gönderme için gerekli tüm verileri içerir: uç nokta, istek gövdesi, zaman damgası ve idempotencyKey. Room veritabanı, uygulama yeniden başlatmalarında ve işletim sistemi çökmelerinde kuyruğun kalıcılığını garanti eder.

Mobil uygulamada neden işlem kuyruğuna ihtiyaç vardır

Teslimat garantisi — kuyruğun temel amacı. Kullanıcı, ağ o anda kullanılamasa bile eyleminin (mesaj gönderme, beğenme, sipariş verme) tamamlanacağından emin olmalıdır. Yeniden deneme mekanizmasına sahip Offline Queue, nihai teslimatı garanti eder.

Kötü bağlantı koşullarında iyileştirilmiş UX — GSMA Mobile Economy Report (2025)'e göre, dünya çapında mobil kullanıcıların yaklaşık %40'ı istikrarsız internet bağlantılarına sahiptir. Offline Queue, uygulamayı metro, asansör, uzak bölgelerde — bağlantının kesintili olduğu her yerde kullanılabilir hale getirir.

Azaltılmış veri kaybı — kuyruk olmadan, çevrimdışı gerçekleştirilen tüm eylemler kaybolur. Bir kullanıcı uzun bir form doldurabilir, “Gönder”'e dokunabilir ve bir ağ hatası görebilir — tüm giriş kaybolur. Offline Queue verileri kaydeder ve ilk fırsatta gönderir. Google Docs'da otomatik kaydetme, belgeler için çevrimdışı kuyruğun klasik bir örneğidir.

Zaman uyumsuz senkronizasyon — kuyruk, uygulamanın gönderme sırasında kullanıcı arayüzünü bloke etmemesini sağlar. Kullanıcı çalışmaya devam ederken senkronizasyon yöneticisi kuyruğu arka planda işler. Bu, Tepkisel Mimari ilkelerini takip eder ve arayüzün yanıt verebilirliğini artırır.

Çevrimdışı kuyruk mimarisi: depolama ve işleme

Kuyruğun üç katmanı: depolama (kalıcılık), zamanlayıcı (scheduler) ve yürütücü. Depolama — QueuedOperation tablosuyla Room. Zamanlayıcı — ağ kullanılabilir olduğunda senkronizasyonu başlatan WorkManager (Android) veya BGTaskScheduler (iOS). Yürütücü — işlemleri tek tek gönderen sıralı bir FIFO yineleyici.

İşlem sırası — veri tutarlılığı için kritiktir. Bir kullanıcı bir kayıt oluşturduysa ve ardından düzenlediyse, her iki işlem de aynı sırayla gönderilmelidir. Aksi takdirde, sunucu önce var olmayan bir kaydın güncellemesini alır — hata. Sıralı FIFO — işlemler arasında bağımlılık kontrolü ile katı sıralama.

Birleştirme stratejisi — kuyrukta bir CREATE ve hemen ardından aynı nesnenin DELETE'i varsa, her iki işlem de gönderilmeden kaldırılabilir: son durum, nesnenin oluşturulmamış olmasıdır. Benzer şekilde, CREATE + UPDATE en son verilerle tek bir CREATE'de birleştirilebilir. Kuyruk optimizasyonu HTTP isteklerinin sayısını azaltır ve senkronizasyonu hızlandırır.

Android Developers (2025)'e göre, WorkManager Android'de Offline Queue'yu işlemenin tercih edilen yoludur: cihaz yeniden başlatıldıktan sonra bile yürütmeyi garanti eder, ağ kısıtlamalarını destekler ve NetworkType.CONNECTED aracılığıyla yeniden deneme politikaları yapılandırmaya izin verir.

class SyncWorker(
    private val context: Context,
    private val params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result = runCatching {
        queueRepository.processNextBatch(batchSize = 10)
        Result.success()
    }.getOrDefault(Result.retry())
}

CoroutineWorker, işlem gruplarını işler ve başarısızlık durumunda Result.retry() döndürür — WorkManager üstel geri alma ile otomatik olarak yeniden dener. Bu, Android'de güvenilir bir Offline Queue elde etmenin en basit yoludur.

Yeniden deneme stratejileri: exponential backoff ve yeniden deneme politikası

Exponential Backoff — artan aralıklarla standart bir yeniden deneme stratejisi: 2 sn, 4 sn, 8 sn, 16 sn ve maksimum eşiğe kadar devam eder. Bu, sunucu geçici olarak kullanılamadığında tekrarlanan aşırı yüklenmeyi önler. Java kitaplığı Resilience4j (2024), yapılandırılabilir geri alma ile hazır bir Retry uygulaması sağlar.

Maksimum deneme sayısı — kritik bir parametre. 5–10 denemeden sonra işlem başarısız olursa, daha fazla yeniden deneme savurgan ve yararsızdır. Bir dead letter queue önerilir: denemeler tükendikten sonra işlem, manuel analiz için ayrı bir tabloya taşınır. Microsoft Patterns & Practices (2024)'e göre, dead letter queue, senkronizasyon sorunlarının hata ayıklamasını basitleştirir ve hatalı işlemlerin kuyruğu bloke etmesini önler.

Jitter — rastgele değişim — geri alma aralığına rastgele bir sayı ekleme. Bin cihaz bir kesintiden sonra aynı anda ağı geri kazanırsa, hepsi aynı anda senkronize olmaya başlar. Jitter onları zamana yayarak sunucuda Cache Stampede'yi önler. Tam jitter: delay = random(0, backoff) — AWS (2024) tarafından API istemcileri için önerilir.

Çakışma çözümü: veri çakışmaları nasıl çözülür

Last Write Wins (LWW) — en basit strateji: çakışma durumunda, daha sonraki zaman damgasına sahip işlem kazanır. LWW, zaman senkronizasyonu gerektirir — zaman damgası sunucuda oluşturulmalı veya Mantıksal Saat (Lamport saatleri) kullanmalıdır. Dezavantaj: bir kullanıcının verileri uyarı yapılmadan başka bir kullanıcının verileri tarafından üzerine yazılabilir.

OT (Operasyonel Dönüşüm) — Google Docs ve Figma tarafından çevrimdışı mod dahil gerçek zamanlı işbirlikçi düzenleme için kullanılan algoritma. OT, işlemleri belgenin herhangi bir durumuna uygulanabilecek şekilde dönüştürerek kilitler olmadan tutarlılık sağlar. CRDT (Çakışmasız Çoğaltılmış Veri Tipleri) — mobil uygulamalarda popülerlik kazanan OT'ye bir alternatif: veriler, merkezi bir sunucu olmadan çakışmaların matematiksel olarak çözülebilmesi için yapılandırılır.

Özel birleştirme — basit veri modellerine (notlar, kişiler) sahip uygulamalar için özel birleştirme kuralları uygulanabilir. Örneğin, bir not için: metin iki sürümde değiştirilmişse, bir ayırıcı ile birleştirme olarak birleştirin. Kullanıcı tarafından çözülen çakışma — otomatik birleştirme imkansızsa, kullanıcıya her iki sürümü de gösterin ve seçmesine izin verin. Dropbox (2024), çevrimdışı dosya çakışmaları için bu yaklaşımı kullanır ve “Conflicted Copy” önekiyle kopyalar oluşturur.

Idempotency keys — tekrarlamaya karşı koruma

Idempotency Key — sunucunun yinelenen istekleri tespit etmek için kullandığı benzersiz bir işlem tanımlayıcısıdır. İstemci aynı anahtarla aynı isteği gönderirse, sunucu yeniden yürütmeden önceden tamamlanmış işlemin sonucunu döndürür. Bu, ağ hataları nedeniyle yeniden göndermelerin mümkün olduğu Offline Queue için kritik öneme sahiptir.

Idempotency key'in biçimi bir UUID veya istek parametrelerinin bir karmasıdır. Sunucu, yinelenenleri tespit etmek için bir süre (genellikle 24 saat) boyunca tamamlanmış anahtarları sonuçla birlikte saklamalıdır. Stripe API (2024) referans örnektir: anahtar Idempotency-Key başlığında iletilir ve aynı anahtarla yinelenen istekler önbelleğe alınmış bir yanıt döndürür.

İstemci tarafı oluşturma — anahtar, işlemi göndermeden önce istemcide oluşturulur ve QueuedOperation tablosunda saklanır. Yeniden denemede anahtar değişmez. Exactly-once mimarisi — istemcide bir idempotency key ve sunucuda yineleme temizleme kombinasyonu, bir işlemin iki kez yürütülmeyeceğini garanti etmenin tek yoludur.

fun createOperation(type: OperationType, payload: String): QueuedOperation =
    QueuedOperation(
        id = UUID.randomUUID().toString(),
        type = type,
        endpoint = type.endpoint,
        payload = payload,
        timestamp = currentTimeMillis(),
        idempotencyKey = UUID.randomUUID().toString()
    )

Her işlem iki UUID alır: biri — kuyruktaki kayıt tanımlayıcısı, ikincisi — sunucu için idempotency key. idempotencyKey ile sunucu tarafı yineleme temizleme, yeniden göndermede bile siparişin tekrarlanmayacağını garanti eder.