Offline Queue: mga prinsipyo, estratehiya, at mekanismo ng paggana

Ano ang offline queue?

Offline Queue ay isang nakaayos na koleksyon ng mga operasyon (paglikha, pag-update, pagtanggal) na lokal na ini-save ng app kapag walang access sa network ang device. Sa sandaling maibalik ang koneksyon, ipinapadala ng pila ang mga operasyon sa server sa parehong pagkakasunud-sunod na ginawa ng user.

Isipin ang isang sitwasyon: ang isang user ng messenger ay nagta-type ng mga mensahe sa subway na walang internet. Bawat pagpindot ng “Ipadala” ay idinaragdag sa Offline Queue. Kapag lumabas na ang tren mula sa tunnel at lumitaw ang network, awtomatikong naipapadala ang lahat ng mensahe. Ang karanasan ng user ay walang putol: hindi niya napapansin na offline siya, maliban sa bahagyang pagkaantala sa pagpapadala.

Ayon sa Uber Engineering (2024), ang kanilang offline queue ay nagpoproseso ng mahigit 2 milyong operasyon bawat araw sa mga rehiyong may mababang kalidad ng koneksyon. Gumagamit ang pila ng lokal na imbakan ng Room na may FIFO order at mekanismo ng garantisadong paghahatid na exactly-once.

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
)

Ang bawat operasyon ay naglalaman ng lahat ng data na kinakailangan para sa muling pagpapadala: endpoint, body ng kahilingan, timestamp, at idempotencyKey. Ang Room database ay ginagarantiyahan ang pagpapanatili ng pila kapag na-restart ang app at nagkaroon ng pag-crash ng OS.

Bakit kailangan ng pila ng operasyon sa mobile app

Garantiya ng paghahatid ay ang pangunahing gawain ng pila. Dapat tiyakin ng user na ang kanyang aksyon (pagpapadala ng mensahe, like, order) ay maisasagawa, kahit na hindi available ang network sa oras ng execution. Ang Offline Queue na may retry mechanism ay tinitiyak ang eventually delivery.

Pagpapabuti ng UX sa mahinang koneksyon — ayon sa GSMA Mobile Economy Report (2025), humigit-kumulang 40% ng mga mobile user sa mundo ay may hindi matatag na koneksyon sa internet. Ginagawang magamit ng Offline Queue ang app sa subway, elevator, malalayong lugar — saanman pasulpot-sulpot ang koneksyon.

Pagbawas ng pagkawala ng data — kung walang pila, lahat ng aksyon na ginawa offline ay mawawala. Maaaring punan ng user ang isang mahabang form, pindutin ang “Ipadala” at makakita ng network error — lahat ng input ay mawawala. Ini-save ng Offline Queue ang data at ipinapadala ito sa unang pagkakataon. Ang auto-save sa Google Docs ay isang klasikong halimbawa ng offline queue para sa mga dokumento.

Asynchronous na pag-sync — pinapayagan ng pila ang app na huwag harangan ang interface habang nagpapadala. Ang user ay patuloy na nagtatrabaho, habang ang sync manager ay nagpoproseso ng pila sa background. Ito ay naaayon sa mga prinsipyo ng Reactive Architecture at nagpapabuti sa pagtugon ng interface.

Arkitektura ng offline queue: pag-iimbak at pagproseso

Tatlong layer ng pila: imbakan (persistence), taga-iskedyul (scheduler), at taga-proseso (executor). Imbakan — Room na may talahanayang QueuedOperation. Taga-iskedyul — WorkManager (Android) o BGTaskScheduler (iOS), na nagpapasimula ng pag-sync kapag may network na. Taga-proseso — isang sequential FIFO iterator na nagpapadala ng mga operasyon nang paisa-isa.

Ang pagkakasunud-sunod ng pagproseso ay kritikal para sa consistency ng data. Kung ang user ay lumikha ng isang record at pagkatapos ay na-edit ito, ang parehong operasyon ay dapat ipadala sa parehong pagkakasunod-sunod. Kung hindi, ang server ay unang makakatanggap ng update ng hindi umiiral na record — error. Sequential FIFO — mahigpit na pagkakasunod-sunod na may kontrol ng mga dependency sa pagitan ng mga operasyon.

Estratehiya ng pagsasama — kung sa pila ay may CREATE at kaagad na DELETE ng parehong bagay, ang parehong operasyon ay maaaring tanggalin nang hindi ipinapadala: ang huling estado — hindi nalikha ang bagay. Katulad nito, ang CREATE + UPDATE CREATE ay maaaring pagsamahin sa isang CREATE na may pinakabagong data. Ang pag-optimize ng pila ay nagbabawas ng bilang ng mga HTTP request at nagpapabilis ng pag-sync.

Ayon sa Android Developers (2025), ang WorkManager ay ang ginustong paraan ng pagproseso ng Offline Queue sa Android: ginagarantiyahan nito ang execution kahit pagkatapos ng restart ng device, sumusuporta sa mga constraint sa pagkakaroon ng network, at nagbibigay-daan sa pagtatakda ng patakaran sa pagsubok muli sa pamamagitan ng 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())
}

Ang CoroutineWorker ay nagpoproseso ng mga batch ng operasyon at nagbabalik ng Result.retry() kapag nabigo — awtomatikong inuulit ng WorkManager ang execution na may exponential delay. Ito ang pinakasimpleng paraan upang makakuha ng maaasahang Offline Queue sa Android.

Mga estratehiya sa pagsubok muli: exponential backoff at retry policy

Exponential Backoff — ang karaniwang estratehiya ng pag-uulit na may dumaraming agwat: 2 segundo, 4 segundo, 8 segundo, 16 segundo, at iba pa hanggang sa maximum na threshold. Pinipigilan nito ang paulit-ulit na pag-overload ng server kung ito ay pansamantalang hindi available. Ang Java library na Resilience4j (2024) ay nagbibigay ng handa nang Retry implementation na may configurable backoff.

Maximum na bilang ng pagsubok — isang kritikal na parameter. Kung pagkatapos ng 5–10 pagsubok ay hindi nagtagumpay ang operasyon, ang karagdagang pagsubok ay walang silbi. Inirerekomenda ang dead letter queue: pagkatapos maubos ang mga pagsubok, ang operasyon ay ililipat sa isang hiwalay na talahanayan para sa manu-manong pagsusuri. Ayon sa Microsoft Patterns & Practices (2024), pinapasimple ng dead letter queue ang pag-debug ng mga problema sa pag-sync at pinipigilan ang pagbara ng pila ng mga maling operasyon.

Jitter — random na pagkakaiba-iba — pagdaragdag ng random na numero sa backoff interval. Kung libu-libong device ang sabay na nag-restore ng koneksyon pagkatapos ng pagkawala, lahat sila ay magsisimula ng pag-sync nang sabay. Ipinapalaganap sila ng Jitter sa oras, na pumipigil sa Cache Stampede sa server. Buong jitter: delay = random(0, backoff) — inirerekomenda ng AWS (2024) para sa mga API client.

Paglutas ng salungatan: paano resolbahin ang mga banggaan ng data

Last Write Wins (LWW) — ang pinakasimpleng estratehiya: sa banggaan, ang operasyon na may mas bagong timestamp ang panalo. Ang LWW ay nangangailangan ng time synchronization — ang timestamp ay dapat gawin sa server o gumamit ng Logical Clock (Lamport clocks). Disbentahe: ang data ng isang user ay maaaring ma-overwrite ng data ng ibang user nang walang babala.

OT (Operational Transformation) — algorithm na ginagamit ng Google Docs at Figma para sa real-time na collaborative editing, kabilang ang offline mode. Binabago ng OT ang mga operasyon upang mailapat ang mga ito sa anumang estado ng dokumento, tinitiyak ang consistency nang walang pagbara. CRDT (Conflict-Free Replicated Data Types) — alternatibo sa OT na nagiging popular sa mga mobile app: ang data ay naka-structure upang ang mga banggaan ay malutas matematikal, nang walang central server.

Custom na pagsasama — para sa mga app na may simpleng modelo ng data (mga tala, contact) maaaring ipatupad ang custom na mga panuntunan sa pagsasama. Halimbawa, para sa isang tala: kung ang teksto ay binago sa dalawang bersyon, pagsamahin ang mga ito bilang concatenation na may separator. Salungatan na naresolba ng user — kung hindi posible ang awtomatikong pagsasama, ipakita sa user ang parehong bersyon at mag-alok ng pagpili. Ginagamit ng Dropbox (2024) ang diskarteng ito para sa mga banggaan sa offline na mga file, na gumagawa ng mga kopya na may prefix na “Conflicted Copy”.

Idempotency keys — proteksyon laban sa pagdoble

Idempotency Key — isang natatanging identifier ng operasyon na ginagamit ng server upang makita ang mga dobleng kahilingan. Kung ang client ay magpapadala ng parehong kahilingan na may parehong key, ibinabalik ng server ang resulta ng naisagawa nang operasyon, nang hindi ito inuulit. Ito ay kritikal para sa Offline Queue, kung saan posible ang muling pagpapadala sa mga network error.

Format ng idempotency key — UUID o hash ng mga parameter ng kahilingan. Dapat i-imbak ng server ang mga naisagawang key kasama ang resulta para sa isang tagal ng panahon (karaniwan ay 24 oras) upang makita ang mga duplicate. Stripe API (2024) — isang halimbawang sanggunian: ang key ay ipinapasa sa header na Idempotency-Key, at ang mga paulit-ulit na kahilingan na may parehong key ay nagbabalik ng naka-cache na tugon.

Pagbuo sa panig ng client — ang key ay ginagawa sa client bago ipadala ang operasyon at ini-save sa talahanayang QueuedOperation. Sa muling pagsubok, hindi nagbabago ang key. Arkitekturang exactly-once — kombinasyon ng idempotency key sa panig ng client at deduplication sa panig ng server — ang tanging paraan upang matiyak na ang isang operasyon ay hindi maisasagawa nang dalawang beses.

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

Ang bawat operasyon ay tumatanggap ng dalawang UUID: isa — identifier ng record sa pila, ang pangalawa — idempotency key para sa server. Ang deduplication sa panig ng server batay sa idempotencyKey ay ginagarantiyahan na kahit sa muling pagpapadala, ang order ay hindi madodoble.