Capacitor SQLite Conflict Resolution: Implementing OR-Sets in High-Altitude Travel Apps

Capacitor SQLite Conflict Resolution: Implementing OR-Sets in High-Altitude Travel Apps

A guide dispatch app operating in the high-altitude valleys of Ladakh will experience complete sync failure the moment network connectivity drops to zero. When adventure tour operators in Leh or local logistics providers in the Nubra Valley send guides into areas with zero cellular reception, their mobile apps must operate completely offline. In these remote locations, network latency frequently spikes past 15,000 milliseconds, and packet loss rates regularly exceed 63%. In this environment, traditional online API-dependent architectures fail. If a booking application loses a transaction due to a network dropout, it suffers immediate financial loss. To survive, mobile software must shift from API-dependent structures to offline-first local database engines that guarantee operation without any active network connection.

Building travel applications for high-altitude environments requires a major paradigm shift. In a typical urban mobile app, write collisions are avoided using centralized databases and locking mechanisms. When a user requests a jeep booking or tour guide assignment, the server verifies availability in a single database transaction. If the slot is open, the server locks it, confirms the booking, and releases the lock. However, this centralized approach fails when users are deep in the Himalayas. Multiple dispatchers operating offline in different valleys can simultaneously book the same tour guide or the same vehicle. When these devices eventually reconnect to a network, their conflicting updates will overwrite each other, causing double-bookings and corrupted database records.

To resolve these offline write collisions, hybrid mobile applications built on frameworks like Capacitor must implement native persistent SQLite databases paired with Conflict-Free Replicated Data Types (CRDTs). Specifically, an Observed-Remove Set (OR-Set) provides a mathematically sound way to handle concurrent additions and deletions across multiple decentralized devices. By tracking every booking mutation in local transactional ledgers, hybrid mobile apps can sync data reliably when cellular signals return. This technical breakdown provides the architectural blueprint and concrete TypeScript implementation needed to deploy OR-Sets and Capacitor SQLite in demanding offline environments.

The Physical and Digital Constraints of High-Altitude App Design

High-altitude regions like Ladakh impose unique constraints on both mobile hardware and network protocols. Designing software for these environments requires an understanding of how extreme cold and spotty infrastructure affect data synchronization.

The Network Topology of Ladakh and Nubra Valley

Ladakh covers a vast geographical area of 59,146 square kilometers characterized by rugged terrain, deep gorges, and high mountain passes. In the administrative hubs of Leh and Kargil, 4G and 5G cellular coverage is relatively stable. However, the moment a tour vehicle moves toward the Nubra Valley, Pangong Tso, or Turtuk, connectivity becomes highly erratic. The physical topology of the region blocks line-of-sight signals from cell towers, creating massive dead zones.

When a cellular connection is available, it is often a low-bandwidth, high-latency 2G or 3G signal. In these conditions, network telemetry reveals harsh realities:

• Extreme Latency: Round-trip times (RTT) routinely jump from a standard 50ms to over 8,400ms.
• Massive Packet Loss: Over patchy cells, packet drop rates range from 45% to 78%, rendering standard TCP handshakes slow and unstable.
• Transient Connections: Connections are often highly transient, lasting for only a few seconds as a vehicle rounds a mountain bend before dropping back to zero.

Standard web-view storage mechanisms like LocalStorage or IndexedDB are not designed for these conditions. If an application relies on a web-view container to store transaction data, it runs the risk of silent storage eviction. On iOS and Android devices, the operating system kernel aggressively reclaims web-view caches under low-memory or low-disk conditions. When a phone drops its connection and RAM usage increases due to continuous background GPS tracking, the OS treats web-view storage as temporary and deletes it. This means local bookings, passenger lists, and guide assignments are lost forever before they can sync to the server.

The Hardware Reality of Sub-Zero Operations

It is not just the network that fails in high-altitude environments; the physical hardware of mobile devices also experiences stress. In Ladakh, operating temperatures during the climbing season can drop well below -15°C. At these temperatures, the lithium-ion batteries in mobile devices become highly unstable. The internal resistance of the battery spikes, causing sudden voltage drops that force the operating system to shut down instantly to protect the hardware.

For an application, a sudden system-level shutdown mid-transaction can corrupt the local database. If the database engine does not enforce strict transaction logs and write-ahead protocols, a partial write will corrupt the database file, making the application unbootable. To prevent this, mobile developers must move away from volatile web-view storage and implement native SQLite databases configured for high durability.

Bypassing the Web-View Sandbox with Capacitor SQLite

Hybrid mobile frameworks like Capacitor run their user interfaces inside a native web-view wrapper (WKWebView on iOS and WebView on Android). While this allows developers to write cross-platform HTML, CSS, and JavaScript, it isolates the application from direct filesystem access. To achieve persistent, durable storage, the application must bypass the web-view sandbox using native plugins.

The Persistence Architecture of Native SQLite

Unlike browser storage APIs, a native SQLite plugin writes database files directly to the application's persistent documents directory on the physical device. On iOS, this is located at /Documents/, and on Android, it is at /data/user/0/app_package/files/. The operating system protects these directories from automated cache cleaning and system memory reclamation.

+-------------------------------------------------------+
|                 Capacitor Web View                    |
|  [ User Interface ]  <--->  [ JavaScript Bridge ]     |
+-------------------------------------------------------+
                                  |
               Serialization / Deserialization (JSON)
                                  |
                                  v
+-------------------------------------------------------+
|                 Capacitor Native Runtime              |
|  [ Swift / Kotlin SQLite Bridge Controller ]           |
+-------------------------------------------------------+
                                  |
                       Direct C API Database Calls
                                  |
                                  v
+-------------------------------------------------------+
|                 Persistent Device Storage             |
|  [ SQLite Database File ] (Full ACID Durability)      |
| - Path (iOS): /Documents/ladakh_offline.db           |
| - Path (Android): /data/user/0/app/ladakh_offline.db|
+-------------------------------------------------------+

To guarantee that database writes survive sudden power failures in cold climates, the SQLite engine must be configured with Write-Ahead Logging (WAL) and strict synchronization rules:

Conflict-Free Replicated Data Types (CRDTs) and the OR-Set

Once persistent native storage is secured, the developer must address the logical challenge of offline write collisions. In a decentralized tour guide dispatch system, guides in different parts of Ladakh will make changes to a shared roster offline. To merge these changes without data loss or manual conflict resolution, the application must use Conflict-Free Replicated Data Types (CRDTs).

The Math of CRDTs: Join-Semilattices

At its mathematical core, a state-based CRDT is a join-semilattice. A join-semilattice is a partially ordered set $(L, \le)$ that supports a merge operator ($\sqcup$) to find the least upper bound (the join) of any two elements $x, y \in L$.

For the merge operator to work reliably across decentralized devices, it must satisfy three core algebraic properties:

Any data structure that satisfies these three mathematical properties can be merged asynchronously across multiple devices without requiring a central coordinator. The databases will eventually converge to the exact same state, a concept known as Strong Eventual Consistency (SEC).

The Observed-Remove Set (OR-Set)

In a travel booking application, managing a list of bookings, assigned vehicles, or available guides is naturally modeled as a set. However, a standard set does not satisfy CRDT requirements. If Client A adds "Guide Tsering" to the assignment list offline, and Client B removes "Guide Tsering" offline, a standard database merge cannot determine which action wins. Without extra metadata, the merge logic cannot distinguish whether the removal happened before or after the addition.

An Observed-Remove Set (OR-Set) resolves this ambiguity by tracking unique tags for every addition and removal.

#### Formal Specification of the OR-Set

An OR-Set $S$ is defined by two internal helper sets: an Add-Set ($A$) and a Remove-Set ($R$):

• The Add-Set ($A$): A set of pairs $(e, t)$, where $e \in E$ is the element being added, and $t \in T$ is a unique tag (such as a UUID or Lamport timestamp) generated at the moment of addition.
• The Remove-Set ($R$): A set of tags that have been removed.

An element $e$ is considered a member of the active set if there exists at least one tag $t$ associated with $e$ in the Add-Set $A$ that does not exist in the Remove-Set $R$.

Mathematically, the active state of the set is defined as:

$$S = \{ e \mid \exists (e, t) \in A \text{ s.t. } t \notin R \}$$

#### The Mechanics of OR-Set Mutations

Let's trace how the OR-Set handles mutations and merges on a local device:

$$A_{\text{merged}} = A_1 \cup A_2$$

$$R_{\text{merged}} = R_1 \cup R_2$$

Because set union ($\cup$) is associative, commutative, and idempotent, the merge operation itself inherits these exact algebraic properties. No matter how many times clients sync, or in what order their payloads arrive at the server, their data converges to the same state.

TypeScript Implementation of an Observed-Remove Set

To implement this logic inside a Capacitor mobile app, we write a production-grade TypeScript class. This class handles elements of any type, maintains internal Add and Remove sets, and provides serialization methods to persist the data inside local SQLite tables.

/**
 * A highly reliable Observed-Remove Set (OR-Set) CRDT.
 * Tracks elements alongside unique tags to allow safe,
 * offline-first concurrent additions and removals.
 */
export class ORSet<T> {
  // Map key is the stringified representation of the element, 
  // and value is a set of unique addition tags.
  private addSet: Map<string, Set<string>>;
  
  // Set storing all removed tags observed by this replica.
  private removeSet: Set<string>;

  constructor(
    serializedAddSet?: [string, string[]][],
    serializedRemoveSet?: string[]
  ) {
    this.addSet = new Map();
    this.removeSet = new Set(serializedRemoveSet || []);

    if (serializedAddSet) {
      for (const [key, tags] of serializedAddSet) {
        this.addSet.set(key, new Set(tags));
      }
    }
  }

  /**
   * Helper utility to serialize complex elements into stable string keys.
   */
  private stringify(element: T): string {
    if (typeof element === 'string') {
      return element;
    }
    // Sort keys during serialization to ensure consistent signatures for identical objects
    return JSON.stringify(element, Object.keys(element).sort());
  }

  /**
   * Helper utility to parse stringified keys back into their typed elements.
   */
  private parse(key: string): T {
    try {
      return JSON.parse(key) as T;
    } catch {
      return key as unknown as T;
    }
  }

  /**
   * Generates a secure, unique tag for mutations.
   * In production, this can combine a device identifier with a Lamport Timestamp.
   */
  private generateUniqueTag(): string {
    const timestamp = Date.now();
    const randomBits = Math.random().toString(36).substring(2, 15);
    return `${timestamp}-${randomBits}`;
  }

  /**
   * Adds an element to the set.
   * Generates a new unique tag, registers it in the local addSet,
   * and returns the generated tag.
   */
  public add(element: T): string {
    const elementKey = this.stringify(element);
    const uniqueTag = this.generateUniqueTag();

    if (!this.addSet.has(elementKey)) {
      this.addSet.set(elementKey, new Set());
    }

    this.addSet.get(elementKey)!.add(uniqueTag);
    return uniqueTag;
  }

  /**
   * Removes an element from the set.
   * Identifies all active tags associated with this element and
   * adds them to the removeSet.
   */
  public remove(element: T): void {
    const elementKey = this.stringify(element);
    const activeTags = this.addSet.get(elementKey);

    if (activeTags) {
      // Add all observed tags for this element to the removeSet
      for (const tag of activeTags) {
        this.removeSet.add(tag);
      }
    }
  }

  /**
   * Evaluates the active members of the set.
   * Returns elements that have at least one addition tag not in the removeSet.
   */
  public value(): T[] {
    const activeElements: T[] = [];

    for (const [elementKey, tags] of this.addSet.entries()) {
      let isElementActive = false;

      for (const tag of tags) {
        if (!this.removeSet.has(tag)) {
          isElementActive = true;
          break;
        }
      }

      if (isElementActive) {
        activeElements.push(this.parse(elementKey));
      }
    }

    return activeElements;
  }

  /**
   * Merges another OR-Set into this instance.
   * Satisfies the Commutative, Associative, and Idempotent properties.
   */
  public merge(other: ORSet<T>): void {
    // 1. Merge Remove Sets (Union of both sets)
    for (const tag of other.removeSet) {
      this.removeSet.add(tag);
    }

    // 2. Merge Add Sets
    for (const [elementKey, otherTags] of other.addSet.entries()) {
      if (!this.addSet.has(elementKey)) {
        this.addSet.set(elementKey, new Set());
      }

      const localTags = this.addSet.get(elementKey)!;
      for (const tag of otherTags) {
        localTags.add(tag);
      }
    }
  }

  /**
   * Serializes the internal state of the OR-Set for persistence in SQLite.
   */
  public serialize(): { addSet: [string, string[]][]; removeSet: string[] } {
    const addSetArray: [string, string[]][] = [];
    for (const [key, tagSet] of this.addSet.entries()) {
      addSetArray.push([key, Array.from(tagSet)]);
    }

    return {
      addSet: addSetArray,
      removeSet: Array.from(this.removeSet)
    };
  }

  /**
   * Factory method to reconstruct an OR-Set from its serialized JSON state.
   */
  public static deserialize<U>(jsonData: {
    addSet: [string, string[]][];
    removeSet: string[];
  }): ORSet<U> {
    return new ORSet<U>(jsonData.addSet, jsonData.removeSet);
  }
}

This TypeScript implementation manages state-based merging. Because it stringifies keys consistently using key-sorting, it supports complex structures, such as custom passenger objects or route-assignment configurations.

Architecture for Local SQL Ledgers and Sync Protocols

To implement this OR-Set CRDT inside our Capacitor application, we store the state in our native SQLite database. Instead of rewriting the entire set state on every user action, we use a local transactional ledger. This approach logs mutations sequentially and applies them to the local SQLite database.

The SQLite Database Schema

The database requires two main tables. The first is sync_ledger, which acts as our write-ahead log for unsynced changes. The second is crdt_store, which acts as the local materialized cache for the current state of our OR-Sets.

-- Represents the write-ahead log of mutations made by the local operator
CREATE TABLE IF NOT EXISTS sync_ledger (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  transaction_uuid TEXT UNIQUE NOT NULL,
  entity_type TEXT NOT NULL,         -- e.g., 'jeep_bookings', 'guide_dispatch'
  action_type TEXT NOT NULL,         -- 'ADD' or 'REMOVE'
  payload TEXT NOT NULL,             -- JSON string of the target element
  mutation_tag TEXT NOT NULL,        -- Unique tag generated for this action
  timestamp_calibrated INTEGER NOT NULL, -- Network-calibrated millisecond timestamp
  sync_status TEXT DEFAULT 'unsynced', -- 'unsynced', 'pending', 'synced'
  retry_count INTEGER DEFAULT 0
);

-- Materialized cache storing the current merged state of the OR-Sets
CREATE TABLE IF NOT EXISTS crdt_store (
  entity_type TEXT PRIMARY KEY,      -- Unique identifier for the set
  add_set_json TEXT NOT NULL,        -- Serialized map of addSet tags
  remove_set_json TEXT NOT NULL,     -- Serialized array of removeSet tags
  last_updated INTEGER NOT NULL
);

-- Speed up query lookups for synchronization
CREATE INDEX IF NOT EXISTS idx_sync_status ON sync_ledger(sync_status);
CREATE INDEX IF NOT EXISTS idx_ledger_timestamp ON sync_ledger(timestamp_calibrated);

The Mutation Pipeline and Materialized Views

When a dispatcher in Leh performs an action (such as assigning a driver to a vehicle), the application executes a localized database transaction:

This two-step process provides dual benefits. By updating crdt_store immediately, the UI responds within milliseconds, providing a fluid user experience even when completely offline. Meanwhile, the sync_ledger records an immutable history of modifications, ready to be transmitted once a network connection is established.

Bidirectional Sync Protocols on Unstable Networks

In high-altitude regions, a standard HTTP POST request will often fail mid-transmission due to high packet loss. To minimize bandwidth usage and increase transmission success rates over weak networks, the synchronization protocol uses delta sync payloads and binary serialization.

+------------------+                   +--------------------+                   +------------------+
| Local client App |                   | GPRS / 3G Network  |                   | Central Database |
| (Capacitor SQLite)|                   | (Leh / Nubra Peak) |                   | (Cloud Postgres) |
+------------------+                   +--------------------+                   +------------------+
         |                                       |                                       |
         | --- 1. Gather 'unsynced' records ---> |                                       |
         | --- 2. Serialize to MessagePack ----->|                                       |
         |                                       | --- 3. Deliver binary payload ------> |
         |                                       |                                       | [Merge payload]
         |                                       |                                       | [Evaluate tags]
         |                                       | <--- 4. Return server mutations ------|
         |                                       | <--- 5. Acknowledge client IDs -------|
         | <--- 6. Apply server delta updates ---|                                       |
         | <--- 7. Mark synced IDs as 'synced' --|                                       |
         v                                       v                                       v

Resolving Double-Booking Write Collisions: A Step-by-Step Scenario

To see the system in action, let's look at a concrete operational scenario. Two tour operators, Tashi in Leh and Rigzin in the Nubra Valley, are managing assignments for a shared fleet of expedition vehicles.

The Scenario Outline

• Shared Asset: A 4x4 Expedition Jeep (License plate: JK-10-A-4432).
• The Conflict: Both operators need to assign a client group to this vehicle for the same calendar slot offline.
• Initial State: The vehicle is unassigned and is empty in the shared OR-Set.

Chronology of Events

#### Step 1: Client Synchronization

While both devices are online in Leh, they synchronize and receive the empty state of the vehicle assignment set.

// Initial state on both devices:
const vehicleAssignment = new ORSet<string>();
console.log(vehicleAssignment.value()); // Output: []

#### Step 2: Going Offline

• Tashi (Leh): Stays online at the central office in Leh.
• Rigzin (Nubra): Travels to the Nubra Valley, crossing the Khardung La pass (altitude: 5,359 meters). He loses all network connectivity.

#### Step 3: Concurrent Offline Modifications

At 10:15 AM, Tashi assigns "Trekker Group A" to the jeep. At 10:17 AM (local system time), Rigzin assigns "Trekker Group B" to the exact same jeep offline in Nubra Valley.

##### Tashi's Action (Leh):

Tashi's device generates an addition mutation.

// Tashi's device executes:
const tagA = vehicleAssignment.add("Group A"); 
// Internal State on Tashi's device:
// addSet: {"Group A" => Set(["1717064100000-tashiDevice1"])}
// removeSet: []
// value(): ["Group A"]

##### Rigzin's Action (Nubra Valley):

Rigzin's device generates a concurrent addition mutation. Because Rigzin's device calculated a calibrated network offset ($\theta$) before going offline, his local transaction is recorded with a reliable timestamp.

// Rigzin's device executes:
const tagB = vehicleAssignment.add("Group B");
// Internal State on Rigzin's device:
// addSet: {"Group B" => Set(["1717064220000-rigzinDevice2"])}
// removeSet: []
// value(): ["Group B"]

At this moment, both devices are out of sync. Tashi's local database shows the jeep is assigned to Group A. Rigzin's local database shows the jeep is assigned to Group B.

#### Step 4: Rigzin Returns to Signal Range

Rigzin returns to Leh and his device reconnects to a network. The synchronization agent initiates a sync transaction. The server pulls mutations from both Tashi's and Rigzin's local database ledgers and performs a merge.

The server's merge logic executes:

const serverSet = new ORSet<string>();

// Merge Tashi's state
serverSet.merge(tashiSet);
// Merge Rigzin's state
serverSet.merge(rigzinSet);

// Resulting internal state on the server:
// addSet: {
//   "Group A" => Set(["1717064100000-tashiDevice1"]),
//   "Group B" => Set(["1717064220000-rigzinDevice2"])
// }
// removeSet: []

When evaluating serverSet.value(), the output is: ["Group A", "Group B"].

Resolving the Concurrent State

Because the OR-Set handles additions commutatively, both assignments are successfully preserved in the merged state. Instead of silently losing one of the assignments-which would happen with a Last-Write-Wins system-the OR-Set exposes the conflict by showing both groups assigned to the same vehicle slot.

The application's scheduling dashboard detects this dual-assignment state and flags it for review. The system can then apply deterministic business logic or alert the coordinator to resolve the issue:

const activeBookings = vehicleAssignment.value();

if (activeBookings.length > 1) {
  // A booking conflict is detected. 
  // Deterministic Resolution: Allocate the vehicle to the earliest booking in the ledger,
  // and flag the second booking for immediate reallocation.
  const earliestBooking = activeBookings.sort((a, b) => {
    // In production, we compare the calibrated timestamps of the addition tags
    return getEarliestTagTimestamp(a) - getEarliestTagTimestamp(b);
  })[0];
  
  console.warn(`Conflict detected for vehicle. Allocating to: ${earliestBooking}`);
}

By utilizing this architecture, the travel agency avoids silent data loss. Both booking attempts are saved, and the operators are presented with a clear alert to manage the conflict.

Frequently Asked Questions

How do we prevent local SQLite database corruption during sudden mobile battery drain in sub-zero Leh climates? {#faq-sqlite-corruption-subzero}

To prevent local database corruption during sudden device shutdowns, developers must enable Write-Ahead Logging (WAL) in SQLite and configure the database with a strict synchronization mode. WAL ensures that modifications are written to an append-only .wal file before they are applied to the main database file. By executing PRAGMA journal_mode=WAL and PRAGMA synchronous=NORMAL inside the Capacitor SQLite connection, you instruct the OS to verify that data is written directly to the storage controller before confirming a successful write. If the device shuts down mid-transaction, SQLite automatically detects the incomplete write upon reboot, rolls back the unfinished transaction, and restores the database to a clean state.

What is the exact conflict resolution strategy for managing concurrent shared vehicle bookings in travel operator apps? {#faq-crdt-double-bookings}

The application uses an Observed-Remove Set (OR-Set) to record booking additions and removals as concurrent mutations rather than database locks. When two operators book the same vehicle offline, their local databases record addition mutations with unique tags and calibrated timestamps. When the devices sync, the server merges these mutations. Because both bookings are preserved in the set, the system detects a conflict (more than one active group assigned to the same vehicle slot). The scheduler resolves this conflict deterministically by assigning the slot to the booking with the earliest calibrated timestamp, while flagging the second booking for immediate reallocation to an alternative vehicle.

How does iOS WebKit cache eviction impact local storage durability in hybrid mobile applications? {#faq-webkit-eviction-risks}

On iOS, the system runs the hybrid application's interface inside a WKWebView container. Standard storage mechanisms like LocalStorage and IndexedDB are classified as temporary caches and are written to directories like /Library/Caches/. When a device runs low on memory or physical storage, iOS's background storage cleaning agent will delete these directories without warning. If an application relies on IndexedDB, all offline bookings and transaction logs can be lost instantly. Bypassing this eviction risk requires utilizing a native SQLite plugin. The plugin writes database files to the application's persistent documents directory (/Documents/), which is protected by the OS kernel and never subjected to automated disk cleanup.

Why do we calculate a network-calibrated clock offset instead of trusting the mobile device's system time? {#faq-clock-drift-calibration}

In remote areas of Ladakh, mobile devices can lose connection to NTP servers and GPS networks for days. Without active time synchronization, the device's internal clock drift can accumulate rapidly, and users may also manually set incorrect system times. If an offline application uses this local system time to timestamp writes, it can corrupt the synchronization timeline. To prevent this, the application calculates a network-calibrated clock offset ($\theta$) on startup using a round-trip time query to the central server. The calculated offset is stored locally in SQLite and applied to every offline transaction time, ensuring a consistent and accurate chronology of events across all devices.

How do we prevent the SQLite local ledger database from ballooning in size on memory-constrained devices? {#faq-sqlite-database-compaction}

Because CRDTs maintain historical metadata to handle conflicts, database files can grow significantly over time. To prevent this storage growth, the sync agent must implement a database compaction process. Once a transaction in the sync_ledger is successfully uploaded to the central server and acknowledged, its individual mutation log is no longer needed locally. The synchronization agent executes a cleanup process that removes all synced rows from sync_ledger that are older than 30 days. It then runs an SQLite VACUUM command to reclaim unused database pages, keeping the application's storage footprint minimal on memory-constrained devices.

If your business operates in Leh, Kargil, or other remote Indian regions and needs a high-performance offline mobile solution, contact us at mailto:bkbtechies@gmail.com - we provide expert, honest technical guidance without high-pressure sales pitches.

Frequently Asked Questions

Q: Why choose OR-Sets over Last-Write-Wins (LWW) for offline travel apps?

A: Last-Write-Wins relies on device clocks, which frequently drift during prolonged offline high-altitude trips and lead to accidental data overwrites. OR-Sets (Observed-Remove Sets) track causality using unique element tags rather than timestamps, guaranteeing deterministic conflict resolution. This ensures concurrent additions and deletions to waypoints or trip logs merge seamlessly without data loss.

Q: How do you store and query OR-Set data inside a Capacitor SQLite database?

A: You can implement OR-Sets in SQLite by maintaining dedicated tables or JSON columns for addition tags (add_set) and removal tags (remove_set). Local additions assign unique UUID tags to items, while deletions copy observed tags into the removal set. During network sync, the app executes SQL set-union queries across local and remote tag sets to derive the active item list.

Q: How do you prevent SQLite database bloat caused by OR-Set tombstones?

A: Because OR-Sets retain tombstone tags to record deletions, storage usage can grow monotonically over long offline periods. To prevent database bloat, implement periodic garbage collection that prunes obsolete tombstones once all client nodes acknowledge a sync state. This keeps the local SQLite database lightweight without compromising conflict-free convergence.

Q: How do OR-Sets handle interrupted syncs caused by weak high-altitude connectivity?

A: OR-Sets are Conflict-Free Replicated Data Types (CRDTs), meaning their merge operations are mathematically commutative, associative, and idempotent. If a network connection drops mid-sync while executing background updates in Capacitor, no data corruption occurs. The app can safely re-send or re-apply the same delta payload once connectivity is restored.

If your business depends on organic search and AI citations, we architect custom Generative Engine Optimization strategies that turn search impressions into qualified pipeline. Explore our SEO & GEO Optimization Retainers or connect with Daniel on WhatsApp at +91 63965 53221 for an architectural review.