Offline Queue: principles, strategies and mechanisms of operation

What is an Offline Queue?

Offline Queue is an ordered collection of operations (create, update, delete) that the application saves locally when the device has no network access. Once the connection is restored, the queue sends operations to the server in the same order the user performed them.

Imagine a scenario: a messenger user types messages in the subway without internet. Each tap of “Send” is added to the Offline Queue. When the train exits the tunnel and network becomes available, all messages are sent automatically. User experience — seamless: they don’t notice they were offline, except for a slight sending delay.

According to Uber Engineering (2024), their offline queue processes over 2 million operations per day in regions with poor connectivity. The queue uses Room local storage with FIFO order and an exactly-once guaranteed delivery mechanism.

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
)

Each operation contains all data necessary for retransmission: endpoint, request body, timestamp, and idempotencyKey. Room database guarantees queue persistence across app restarts and OS crashes.

Why an operation queue is needed in a mobile app

Delivery guarantee — the main purpose of the queue. The user must be confident that their action (sending a message, like, order) will be completed, even if the network is unavailable at the moment. Offline Queue with retry mechanism ensures eventual delivery.

Improved UX in poor connectivity conditions — according to GSMA Mobile Economy Report (2025), about 40% of mobile users worldwide have unstable internet connections. Offline Queue makes the app usable in subways, elevators, remote areas — everywhere connectivity is intermittent.

Reduced data loss — without a queue, all actions performed offline are lost. A user could fill out a long form, tap “Submit” and see a network error — all input is lost. Offline Queue saves data and sends it at the first opportunity. Auto-save in Google Docs is a classic example of an offline queue for documents.

Asynchronous synchronization — the queue allows the app not to block the UI during sending. The user continues working while the sync manager processes the queue in the background. This follows Reactive Architecture principles and improves interface responsiveness.

Offline queue architecture: storage and processing

Three layers of the queue: storage (persistence), scheduler, and executor. Storage — Room with a QueuedOperation table. Scheduler — WorkManager (Android) or BGTaskScheduler (iOS) that triggers synchronization when network becomes available. Executor — a sequential FIFO iterator that sends operations one by one.

Processing order — critical for data consistency. If a user created a record and then edited it, both operations must be sent in the same order. Otherwise, the server first receives an update for a non-existent record — an error. Sequential FIFO — strict ordering with dependency control between operations.

Merge strategy — if the queue has a CREATE followed immediately by a DELETE of the same object, both operations can be removed without sending: the final state is that the object is not created. Similarly, CREATE + UPDATE can be merged into one CREATE with the latest data. Queue optimization reduces the number of HTTP requests and speeds up synchronization.

According to Android Developers (2025), WorkManager is the preferred way to handle Offline Queue on Android: it guarantees execution even after device restart, supports network constraints, and allows configuring retry policies through 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 processes operation batches and returns Result.retry() on failure — WorkManager automatically retries with exponential backoff. This is the simplest way to get a reliable Offline Queue on Android.

Retry strategies: exponential backoff and retry policy

Exponential Backoff — a standard retry strategy with increasing intervals: 2 sec, 4 sec, 8 sec, 16 sec and so on up to a maximum threshold. This prevents repeated server overload if it is temporarily unavailable. The Java library Resilience4j (2024) provides a ready-made Retry implementation with configurable backoff.

Maximum retry count — a critical parameter. If after 5–10 attempts the operation fails, further retries are wasteful and useless. A dead letter queue is recommended: after retries are exhausted, the operation is moved to a separate table for manual analysis. According to Microsoft Patterns & Practices (2024), a dead letter queue simplifies debugging synchronization issues and prevents faulty operations from blocking the queue.

Jitter — random variation — adding a random number to the backoff interval. If a thousand devices regain network simultaneously after an outage, they all start syncing at the same time. Jitter spreads them out over time, preventing Cache Stampede on the server. Full jitter: delay = random(0, backoff) — recommended by AWS (2024) for API clients.

Conflict resolution: how to resolve data collisions

Last Write Wins (LWW) — the simplest strategy: in case of conflict, the operation with the later timestamp wins. LWW requires time synchronization — the timestamp must be generated on the server or use a Logical Clock (Lamport clocks). Disadvantage: one user’s data may be overwritten by another user’s data without warning.

OT (Operational Transformation) — the algorithm used by Google Docs and Figma for real-time collaborative editing, including offline mode. OT transforms operations so they can be applied to any document state, ensuring consistency without locks. CRDT (Conflict-Free Replicated Data Types) — an alternative to OT gaining popularity in mobile apps: data is structured so that conflicts are mathematically resolvable without a central server.

Custom Merge — for apps with simple data models (notes, contacts), custom merge rules can be implemented. For example, for a note: if text is modified in two versions, merge them as concatenation with a separator. User-resolved conflict — if automatic merging is impossible, show the user both versions and let them choose. Dropbox (2024) uses this approach for offline file conflicts, creating copies with the “Conflicted Copy” prefix.

Idempotency keys — protection against duplication

Idempotency Key — a unique operation identifier that the server uses to detect duplicate requests. If the client sends the same request with the same key, the server returns the result of the already completed operation without executing it again. This is critically important for Offline Queue, where retransmissions are possible due to network errors.

The format of the idempotency key is a UUID or a hash of request parameters. The server must store completed keys along with the result for some time (usually 24 hours) to detect duplicates. Stripe API (2024) is the reference example: the key is passed in the Idempotency-Key header, and repeated requests with the same key return a cached response.

Client-side generation — the key is created on the client before sending the operation and stored in the QueuedOperation table. On retry, the key does not change. Exactly-once architecture — the combination of an idempotency key on the client and deduplication on the server is the only way to guarantee that an operation is not executed twice.

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

Each operation gets two UUIDs: one — the record identifier in the queue, the second — the idempotency key for the server. Server-side deduplication by idempotencyKey guarantees that even on retransmission, the order will not be duplicated.