Offline Operation Scenarios: What to Do When the Internet Goes Down?

What is Offline-First Architecture?

Offline-first architecture solves connectivity issues at the design stage

Traditional web and mobile applications operate on an “online-first” logic: the user performs an action, a request is sent to the server, a response is returned, and the result is displayed. This model assumes a continuous and reliable internet connection.

Offline-first architecture reverses this assumption: the application is designed to perform all core functions even without an internet connection. Data is synchronized in the background when a connection is available.

Core Principles of Offline-First

• Local-first data: Data is stored first on the local device (phone, tablet, local server)
• Asynchronous synchronization: Data is transmitted to the center in the background when a connection is available
• Conflict management: If the same data is changed in different locations, it is resolved using predefined rules
• Progressive enhancement: Additional features are enabled when online, while core functions work when offline

Why Offline-First?

The offline working scenario is critical not only for internet outages but also in the following situations:

• Field teams working in low-bandwidth regions
• Warehouses underground or inside metal structures where RF signals cannot be received
• Teams operating in remote locations (construction sites, mines, agricultural fields)
• Traveling personnel who want to reduce roaming costs abroad
• Production lines where uninterrupted operation is mandatory

Industry-based applications show that offline capabilities have become a standard expectation, especially in the manufacturing, logistics, and retail sectors.

Local Caching Strategies

The right cache strategy forms the foundation of the offline experience

The heart of the offline working scenario is the local data storage mechanism. Data required by the user must be pre-downloaded, and transaction results must be stored securely.

Browser-Based Cache Options

localStorage and sessionStorage

Suitable for simple key-value storage. Limitations: 5-10 MB capacity, string data only, synchronous API. Use cases: user preferences, recently viewed items, form drafts.

IndexedDB

A NoSQL database designed for large volumes of structured data. Advantages: hundreds of MB capacity, indexing and querying, asynchronous API. Use cases: product catalogs, customer lists, offline transaction queues.

Cache API (Service Worker)

Used to cache HTTP responses. Ideal for static files (HTML, CSS, JS, images) and API responses. It is a fundamental component of PWAs.

Mobile Application Cache Options

SQLite

A relational database supported natively on both iOS and Android. Advantages: SQL query support, transaction guarantees, large datasets. The majority of enterprise mobile applications use SQLite.

Realm Database

An object database optimized for mobile. Advantages: fast read/write, reactive queries, automatic synchronization support. Preferred especially in real-time applications.

Core Data (iOS) / Room (Android)

Platform-native ORM layers. Advantages: platform integration, memory management, migration support. Disadvantage: cross-platform code sharing becomes difficult.

Cache Strategies

• Cache-first: Check the cache first, otherwise go to the network. Ideal for offline-priority applications.
• Network-first: Go to the network first, fall back to the cache if it fails. Used when up-to-date data is critical.
• Stale-while-revalidate: Return from cache immediately, update in the background. Balances speed and freshness.
• Cache-only: Return only from cache. Suitable for static content.
• Network-only: Fetch only from the network. Used for real-time data.

Synchronization Mechanisms

Reliable synchronization preserves data integrity

The most critical component of the offline working scenario is how local changes are transmitted to the center. Synchronization must preserve data integrity without disrupting the user experience.

Synchronization Models

Full Sync

The entire dataset is compared during each synchronization. Advantage: simplicity. Disadvantage: slow and bandwidth-intensive for large datasets. Use case: small datasets, master data that changes rarely.

Delta Sync

Only records changed since the last synchronization are transmitted. Tracked via timestamp or version number. The standard approach in enterprise applications.

Event Sourcing

Events are synchronized instead of data changes. The central server applies the events to create the current state. Advantage: easier conflict resolution, audit trail. Disadvantage: complex implementation.

Synchronization Triggers

• When connection returns: Network status is monitored, starts automatically when online
• Periodic: Checked at specific intervals (e.g., every 5 minutes)
• User-triggered: Initiated via a manual “sync” button
• Transaction-based: Synchronization is attempted immediately after critical transactions
• Background sync: Works in the background via Service Worker, even when the application is closed

Queue Management

Offline transactions are held in a queue. Key considerations for queue management:

• Ordering: Placing transactions in the correct order (e.g., create customer first, then enter order)
• Retry logic: Retrying failed transactions, exponential backoff
• Idempotency: Ensuring that sending the same transaction multiple times is harmless
• Timeout: Canceling or flagging very old transactions

Conflict Resolution Methods

Data conflicts are inevitable; what matters is the right resolution strategy

Multiple users or devices may edit the same data offline. When the connection is restored, these changes conflict. Conflict resolution determines how these conflicts are handled.

Automatic Resolution Strategies

Last-Write-Wins (LWW)

The most recent change prevails. Easy to implement but carries a risk of data loss. Use case: non-critical data, log records, preference settings.

First-Write-Wins (FWW)

The first change prevails, subsequent ones are rejected. Use case: first-come-first-served scenarios (e.g., stock reservation).

Merge

Both changes are preserved and combined. Field-level merging allows changes in different fields to be combined automatically. Use case: document collaboration, list addition operations.

Version Vectors / CRDT

Conflict-free Replicated Data Types provide a mathematically guaranteed conflict-free merge. Advantage: automatic, consistent resolution. Disadvantage: not suitable for every data type, complex implementation.

Situations Requiring Manual Resolution

Some conflicts cannot be resolved automatically and require user intervention:

• Writing different values to the same field (e.g., different price entries)
• Situations where business rules are violated (e.g., selling more than available stock)
• Changes with critical financial or legal consequences

Conflict Prevention

The best conflict resolution is to prevent conflicts from occurring:

• Pessimistic locking: Others cannot edit the record while it is being edited (requires online)
• Optimistic locking: Checked via record version number
• Partition by user: Each user edits their own data (no possibility of conflict)
• Append-only: Data is not updated, new records are added (log approach)

Offline Mode in Mobile Applications

Mobile applications are the most common use case for offline work

Field teams, delivery personnel, sales representatives, and technical service teams work with mobile devices. For these users, an offline working scenario means business continuity.

Native vs Hybrid vs PWA

Native Mobile Application

Advantages: full hardware access, best performance, advanced offline capabilities. Disadvantages: separate iOS/Android development, app store approval process, update distribution.

Hybrid Application (React Native, Flutter)

Advantages: single codebase, near-native performance, offline plugin ecosystem. Disadvantages: not as flexible as native, limited access to some platform features.

Progressive Web App (PWA)

Advantages: no installation required, automatic updates, cross-platform. Disadvantages: limited hardware access, restricted Service Worker support on iOS, performance issues with large datasets.

Offline Mobile Application Features

• Background sync: Synchronization while the app is in the background
• Push notification queue: Queuing notifications received while offline
• Selective sync: Downloading only the data the user needs
• Bandwidth-aware sync: Sync behavior based on connection type (WiFi/mobile data)
• Offline indicator: Clearly showing the connection status to the user
• Pending operations display: List and status of pending transactions

Mobile Offline Best Practices

• Pre-cache critical data
• Lazy-load large files (images, PDF)
• Define and notify users of offline transaction limits
• Optimize battery consumption (sync frequency, background activity)
• Monitor storage usage and clear old data

The Role of Edge Computing and Local Processing

Edge computing moves processing to where the data is

Edge computing performs data processing at points close to the user instead of a central cloud. In an offline working scenario, edge nodes can maintain local operations even without an internet connection.

Edge Node Types

On-Premise Mini Server

A small server located within a factory, warehouse, or store. Works on the local network and can maintain all local operations when the internet connection is lost. Synchronizes with the center when the connection is restored.

IoT Gateway

A device that collects data from sensors and machines and performs pre-processing. Stores data locally when offline and sends it in batches when the connection is restored. Common in production and logistics environments.

Thick Client

An application that runs on the user’s workstation and contains comprehensive business logic. Unlike browser-based thin clients, it offers full offline functionality. ERP desktop clients fall into this category.

Edge Computing Advantages

• Low latency: Data does not need to travel to the center and back
• Bandwidth optimization: Only summary/aggregated data goes to the center
• Offline resilience: Working without an internet connection
• Data privacy: Sensitive data can remain local
• Regulatory compliance: The requirement that some data cannot leave the country/region

Edge-Cloud Hybrid Architecture

A modern offline working scenario combines edge and cloud:

• Edge layer: Real-time transactions, local cache, offline capability
• Cloud layer: Central data repository, analytics, reporting, backup
• Sync layer: Reliable data transfer between edge and cloud

Field Example: Offline Transformation of a Distribution Company

Real Case (Unbranded)

Situation

An FMCG distributor with a fleet of 120 vehicles. Average of 8,000 delivery points per day. Order/delivery application on mobile handheld terminals. Problem: Orders are lost during internet outages in rural areas, and real-time stock tracking is not possible.

Steps Taken

1. Offline-first redesign: Mobile application rewritten with an SQLite-based local database
2. Daily route pre-cache: Every morning, the driver downloads that day’s customer list, price, and stock information
3. Offline order entry: Orders are taken without internet and stored locally
4. Smart sync: Automatic synchronization when WiFi is available (warehouse, store)
5. Conflict policy: “First-come-first-served” for stock conflicts, central price prevails for price conflicts
6. Edge server: Local server in each regional warehouse supports intra-regional offline work

Result (Representative)

• Lost order rate: Dropped from 3.2% to 0.1%
• Driver productivity increase: 18% (reduced waiting time)
• IT support calls: Decreased by 45% (for connectivity issues)
• Real-time stock visibility: Increased to 94%

7 Most Common Mistakes in Offline Scenarios

1. Not Testing the Offline State

Development and test environments have constant internet connectivity. Applications deployed to production without simulating the real offline state cause problems in the field. Chrome DevTools “Offline” mode is not enough; testing on a real device is essential.

2. Assuming Unlimited Offline Duration

The system might work offline for 1 hour, but what happens if it stays offline for 1 week? The accumulated data volume, stale data risk, and synchronization complexity must be calculated. Reasonable offline duration limits must be set.

3. Not Planning Conflict Resolution

The “we’ll see if a conflict occurs” approach. Conflict scenarios must be determined at the design stage, and a resolution strategy must be documented for each data type. Otherwise, users will encounter inconsistent data.

4. Not Informing the User

The user doesn’t know they are working offline and doesn’t see that their transactions are pending. A clear offline indicator and pending operations display are mandatory. User uncertainty leads to a loss of trust.

5. Trying to Download All Data

100,000 products, 50,000 customers… downloading everything to a mobile device is unnecessary and impossible. The dataset the user needs must be determined via selective sync. Otherwise, storage and performance issues will arise.

6. Lack of Synchronization Error Management

What happens if the sync fails? Retry logic, error logging, user notification, and manual intervention options must be planned. Synchronization that “fails silently” leads to data loss.

7. Neglecting Security

Is the data stored offline encrypted? What happens if the device is lost or stolen? Local database encryption, secure storage, and remote wipe capabilities are mandatory in offline applications.

Proper planning prevents data loss in offline scenarios

Offline Working Success Metrics

The following metrics can be used to measure the success of an offline working scenario (representative values):

Offline Preparation Checklist (16+ Items)

Frequently Asked Questions (FAQ)