Offline Queue: prinsip, strategi, dan mekanisme kerja

Apa itu antrean offline?

Offline Queue adalah koleksi operasi terurut (buat, perbarui, hapus) yang disimpan secara lokal oleh aplikasi ketika perangkat tidak memiliki akses jaringan. Begitu koneksi pulih, antrean mengirim operasi ke server dalam urutan yang sama seperti yang dilakukan pengguna.

Bayangkan skenario: pengguna aplikasi pesan mengetik pesan di kereta bawah tanah tanpa internet. Setiap kali tombol “Kirim” ditekan, operasi ditambahkan ke Offline Queue. Saat kereta keluar dari terowongan dan jaringan muncul, semua pesan terkirim secara otomatis. Pengalaman pengguna mulus: dia tidak menyadari sedang offline, kecuali sedikit keterlambatan saat mengirim.

Menurut Uber Engineering (2024), antrean offline mereka memproses lebih dari 2 juta operasi per hari di wilayah dengan kualitas koneksi rendah. Antrean menggunakan penyimpanan lokal Room dengan urutan FIFO dan mekanisme pengiriman exactly-once yang terjamin.

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
)

Setiap operasi berisi semua data yang diperlukan untuk pengiriman ulang: endpoint, badan permintaan, stempel waktu, dan idempotencyKey. Basis data Room menjamin ketahanan antrean saat aplikasi di-restart dan terjadi kerusakan sistem operasi.

Mengapa antrean operasi diperlukan di aplikasi seluler

Jaminan pengiriman adalah tugas utama antrean. Pengguna harus yakin bahwa tindakannya (mengirim pesan, like, pesanan) akan dilakukan, bahkan jika jaringan tidak tersedia pada saat eksekusi. Offline Queue dengan mekanisme retry memastikan pengiriman eventually.

Peningkatan UX dalam kondisi koneksi buruk — menurut GSMA Mobile Economy Report (2025), sekitar 40% pengguna seluler di dunia memiliki koneksi internet yang tidak stabil. Offline Queue membuat aplikasi dapat digunakan di kereta bawah tanah, lift, daerah terpencil — di mana pun koneksi terputus-putus.

Pengurangan kehilangan data — tanpa antrean, semua tindakan yang dilakukan secara offline akan hilang. Pengguna dapat mengisi formulir panjang, menekan “Kirim” dan melihat kesalahan jaringan — semua input hilang. Offline Queue menyimpan data dan mengirimnya pada kesempatan pertama. Penyimpanan otomatis di Google Docs adalah contoh klasik antrean offline untuk dokumen.

Sinkronisasi asinkron — antrean memungkinkan aplikasi untuk tidak memblokir antarmuka selama pengiriman. Pengguna terus bekerja, sementara manajer sinkronisasi memproses antrean di latar belakang. Ini sesuai dengan prinsip Arsitektur Reaktif dan meningkatkan responsivitas antarmuka.

Arsitektur antrean offline: penyimpanan dan pemrosesan

Tiga lapisan antrean: penyimpanan (persistence), penjadwal (scheduler), dan pemroses (executor). Penyimpanan — Room dengan tabel QueuedOperation. Penjadwal — WorkManager (Android) atau BGTaskScheduler (iOS), yang memulai sinkronisasi saat jaringan tersedia. Pemroses — iterator FIFO sekuensial yang mengirim operasi satu per satu.

Urutan pemrosesan sangat penting untuk konsistensi data. Jika pengguna membuat catatan lalu mengeditnya, kedua operasi harus dikirim dalam urutan yang sama. Jika tidak, server akan menerima pembaruan catatan yang tidak ada — kesalahan. Sequential FIFO — urutan ketat dengan kontrol ketergantungan antar operasi.

Strategi penggabungan — jika dalam antrean terdapat CREATE dan segera setelahnya DELETE dari objek yang sama, kedua operasi dapat dihapus tanpa dikirim: status akhir — objek tidak dibuat. Demikian pula, CREATE + UPDATE CREATE dapat digabung menjadi satu CREATE dengan data terbaru. Optimasi antrean mengurangi jumlah permintaan HTTP dan mempercepat sinkronisasi.

Menurut Android Developers (2025), WorkManager adalah cara yang paling disukai untuk memproses Offline Queue di Android: ia menjamin eksekusi bahkan setelah perangkat di-restart, mendukung batasan ketersediaan jaringan, dan memungkinkan pengaturan kebijakan percobaan ulang melalui NetworkType.CONNECTED.

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 memproses batch operasi dan mengembalikan Result.retry() saat gagal — WorkManager secara otomatis mengulang eksekusi dengan penundaan eksponensial. Ini adalah cara termudah untuk mendapatkan Offline Queue yang andal di Android.

Strategi percobaan ulang: exponential backoff dan retry policy

Exponential Backoff — strategi pengulangan standar dengan interval yang meningkat: 2 detik, 4 detik, 8 detik, 16 detik, dan seterusnya hingga ambang maksimum. Ini mencegah pembebanan berulang pada server jika server tidak tersedia sementara. Pustaka Java Resilience4j (2024) menyediakan implementasi Retry siap pakai dengan backoff yang dapat dikonfigurasi.

Jumlah percobaan maksimum — parameter penting. Jika setelah 5–10 percobaan operasi tidak berhasil, percobaan lebih lanjut tidak berguna. Dead letter queue direkomendasikan: setelah percobaan habis, operasi dipindahkan ke tabel terpisah untuk analisis manual. Menurut Microsoft Patterns & Practices (2024), dead letter queue menyederhanakan debugging masalah sinkronisasi dan mencegah pemblokiran antrean oleh operasi yang salah.

Jitter — variasi acak — penambahan angka acak ke interval backoff. Jika ribuan perangkat secara bersamaan memulihkan koneksi setelah pemutusan, semuanya akan memulai sinkronisasi secara bersamaan. Jitter menyebarkannya dalam waktu, mencegah Cache Stampede di server. Jitter penuh: delay = random(0, backoff) — direkomendasikan oleh AWS (2024) untuk klien API.

Resolusi konflik: cara menyelesaikan bentrokan data

Last Write Wins (LWW) — strategi paling sederhana: saat terjadi konflik, operasi dengan stempel waktu terbaru menang. LWW memerlukan sinkronisasi waktu — timestamp harus dihasilkan di server atau menggunakan Logical Clock (jam Lamport). Kekurangan: data satu pengguna dapat ditimpa oleh data pengguna lain tanpa peringatan.

OT (Operational Transformation) — algoritma yang digunakan oleh Google Docs dan Figma untuk pengeditan bersama secara real-time, termasuk mode offline. OT mengubah operasi sehingga dapat diterapkan ke status dokumen apa pun, memastikan konsistensi tanpa pemblokiran. CRDT (Conflict-Free Replicated Data Types) — alternatif OT yang semakin populer di aplikasi seluler: data terstruktur sehingga konflik dapat diselesaikan secara matematis, tanpa server pusat.

Penggabungan kustom — untuk aplikasi dengan model data sederhana (catatan, kontak) aturan penggabungan kustom dapat diimplementasikan. Misalnya, untuk catatan: jika teks diubah dalam dua versi, gabungkan sebagai konkatenasi dengan pemisah. Konflik yang diselesaikan pengguna — jika penggabungan otomatis tidak memungkinkan, tampilkan kedua versi kepada pengguna dan tawarkan pilihan. Dropbox (2024) menggunakan pendekatan ini untuk konflik pada file offline, membuat salinan dengan awalan “Conflicted Copy”.

Idempotency keys — perlindungan dari duplikasi

Idempotency Key — pengidentifikasi unik operasi yang digunakan server untuk mendeteksi permintaan duplikat. Jika klien mengirim permintaan yang sama dengan kunci yang sama, server mengembalikan hasil operasi yang sudah dilakukan, tanpa menjalankannya lagi. Ini sangat penting untuk Offline Queue, di mana pengiriman ulang mungkin terjadi karena kesalahan jaringan.

Format idempotency key — UUID atau hash dari parameter permintaan. Server harus menyimpan kunci yang sudah dilakukan bersama hasilnya untuk jangka waktu tertentu (biasanya 24 jam) untuk mendeteksi duplikat. Stripe API (2024) — contoh referensi: kunci dikirimkan di header Idempotency-Key, dan permintaan berulang dengan kunci yang sama mengembalikan respons yang di-cache.

Pembuatan di sisi klien — kunci dibuat di klien sebelum mengirim operasi dan disimpan di tabel QueuedOperation. Saat percobaan ulang, kunci tidak berubah. Arsitektur exactly-once — kombinasi idempotency key di sisi klien dan deduplikasi di sisi server — satu-satunya cara untuk menjamin bahwa operasi tidak akan dilakukan dua kali.

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()
    )

Setiap operasi mendapat dua UUID: satu — pengidentifikasi catatan dalam antrean, kedua — idempotency key untuk server. Deduplikasi di sisi server berdasarkan idempotencyKey menjamin bahwa bahkan saat pengiriman ulang, pesanan tidak akan diduplikasi.