Sync & Replication: Conflict Handling, Offline-First & Data Consistency

TAKEAWAYS:

• Conflict resolution in mobile apps uses last-write-wins, client-driven, or server-driven strategies, each with trade-offs for offline-first apps.
• Optimistic vs. pessimistic locking determines how apps handle concurrent edits (e.g., Google Docs vs. a bank’s transaction log).
• Replication models (master-slave, peer-to-peer, hybrid) dictate how data is copied and synchronized, with latency and cost implications.
• Offline-first design relies on local storage (SQLite, IndexedDB) and sync queues to resume operations when connectivity returns.
• Eventual consistency (e.g., WhatsApp messages) vs. strong consistency (e.g., Ncell billing) balances user experience and data accuracy.
• Delta synchronization (only syncing changed data) reduces bandwidth usage, critical for low-connectivity areas like rural Nepal.

1. Why Synchronization Matters in Mobile Apps

Mobile apps often operate in intermittent connectivity—users toggle between online/offline modes. Without proper synchronization:

• Data gets lost or duplicated (e.g., a Daraz order placed offline but not synced).
• Conflicts arise when two devices edit the same record (e.g., two users updating the same eSewa transaction).
• Performance degrades if apps fetch full datasets repeatedly (e.g., NEPSE stock data).

Key Challenges

mindmap
  root((Synchronization Challenges))
    Intermittent Connectivity
      "Offline edits pending"
      "Sync queues overflow"
    Data Conflicts
      "Last-write-wins vs. merge strategies"
      "Timestamp vs. version vectors"
    Bandwidth Constraints
      "Delta sync vs. full resync"
    Latency
      "Real-time vs. batch updates"

2. Conflict Resolution Strategies

When two devices modify the same data, apps must resolve conflicts. Three common approaches:

Worked Example: eSewa Payment Conflict

Scenario: User A pays ₹1000 for a bus ticket via eSewa offline. User B also pays ₹1000 for the same ticket online before User A syncs. Conflict Resolution:

1. Last-Write-Wins: Server keeps User B’s payment (User A’s ₹1000 is lost).
2. Client-Driven: App shows both payments and lets the user choose (e.g., "Select which payment to keep").
3. Server-Driven: Server rejects User A’s payment with an error: "Ticket already paid by another user."

Trace Table:

3. Replication Models for Mobile Data

Replication copies data across devices/servers to improve availability. Three models:

A. Master-Slave Replication

• How it works: One master server handles writes; slave servers replicate data for reads.
• Example: Ncell’s customer database (master in Kathmandu, slaves in regional offices).
• Pros: Strong consistency, simple to implement.
• Cons: Single point of failure (master), high latency for remote slaves.

graph LR
  A["Master Server"] -->|"Writes"| B["Slave 1"]
  A -->|"Writes"| C["Slave 2"]
  B -->|"Reads"| D["User 1"]
  C -->|"Reads"| E["User 2"]

B. Peer-to-Peer (P2P) Replication

• How it works: All devices are equal; changes propagate via gossip protocols (e.g., WhatsApp).
• Example: Pathao driver apps sync ride requests directly between drivers’ phones.
• Pros: No single point of failure, works offline.
• Cons: Eventual consistency, complex conflict resolution.

graph TD
  A["Device 1"] -- Sync --> B["Device 2"]
  B -- Sync --> C["Device 3"]
  C -- Sync --> A

C. Hybrid Replication

• How it works: Combines master-slave (for critical data) and P2P (for non-critical data).
• Example: Daraz’s inventory system (master for orders, P2P for product catalog updates).
• Pros: Balances consistency and scalability.
• Cons: Higher implementation complexity.

Comparison Table:

4. Offline-First Design Principles

Apps like Khalti or NTC’s mobile ticketing must work offline and sync later. Key techniques:

A. Local Storage Options

B. Sync Queues

When offline, apps store pending changes in a sync queue (e.g., a SQLite table or Redis list). On reconnect:

1. Fetch server state.
2. Merge local changes.
3. Push resolved changes to the server.

Example: NTC Train Ticket Sync

sequenceDiagram
  participant User
  participant App
  participant SyncQueue
  participant Server
  User->>App: Book ticket offline
  App->>SyncQueue: Store {ticket_id: 123, status: "pending"}
  loop Every 5 mins
    App->>Server: Check connectivity
  end
  Server-->>App: Connection established
  App->>SyncQueue: Pop pending ticket
  App->>Server: Push {ticket_id: 123, status: "confirmed"}
  Server-->>App: Acknowledge

C. Delta Synchronization

Instead of resyncing entire datasets, apps sync only deltas (changes since last sync). Reduces bandwidth by 90%+ for apps like NEPSE’s stock data.

Worked Example: Daraz Order Sync

• Full Sync: 10 MB of product catalog.
• Delta Sync: Only 100 KB (new products/price changes).

Trace Table:

5. Consistency Models

Trade-offs between consistency, availability, and partition tolerance (CAP theorem).

6. Real-World Applications

A. eSewa: Optimistic Locking for Payments

• Problem: Users may edit payment details offline.
• Solution: Uses version vectors to track edit sequences.
  • If two users edit the same transaction, eSewa shows a merge conflict screen.
• Result: No silent data loss, but requires user intervention.

B. Pathao: P2P Replication for Ride Requests

• Problem: Drivers need real-time ride updates, even offline.
• Solution: Ride requests replicate via gossip protocol between drivers’ phones.
  • If two drivers accept the same ride, the server resolves it via last-write-wins (timestamp-based).
• Result: Faster response times in low-connectivity areas.

C. NEPSE: Delta Sync for Stock Data

• Problem: Full stock data syncs (100 MB) are too slow for mobile.
• Solution: Only syncs price changes and new listings (delta sync).
• Result: 95% bandwidth reduction; users see near-real-time updates.

7. Algorithms for Conflict Resolution

A. Merge Algorithm (Client-Driven)

Used in apps like Google Docs to combine edits.

def merge_changes(local_data, server_data, conflict_resolver):
    merged = server_data.copy()  # Start with server as base
    for local_change in local_data:
        if local_change["id"] not in merged:
            merged.append(local_change)
        else:
            # Resolve conflict (e.g., take latest timestamp)
            server_idx = next(i for i, x in enumerate(merged) if x["id"] == local_change["id"])
            if local_change["timestamp"] > merged[server_idx]["timestamp"]:
                merged[server_idx] = local_change
            else:
                conflict_resolver(merged[server_idx], local_change)
    return merged

Trace Example:

B. Timestamp-Based Conflict Resolution

Used in WhatsApp to order messages.

flowchart TD
  A["Compare timestamps"] -->|"Local > Server"| B["Use local change"]
  A -->|"Server > Local"| C["Use server change"]
  A -->|"Equal"| D["Prompt user to choose"]

Exam Tip

What Examiners Look For

1. Definitions: Clearly distinguish between strong consistency, eventual consistency, and delta sync.
2. Trade-offs: For each replication model, explain one advantage and one disadvantage (e.g., "Master-slave is consistent but fails if the master crashes").
3. Real-World Mapping: Relate concepts to Nepali apps (e.g., "eSewa uses client-driven conflict resolution for payments").
4. Diagrams: Draw before/after sync states (e.g., SQLite database after a merge).
5. Code Traces: Show step-by-step execution of a sync algorithm (e.g., merge function table).

Common Pitfalls

• Assuming all apps use strong consistency: Most mobile apps (e.g., WhatsApp) use eventual consistency.
• Ignoring offline queues: Many students forget to mention how apps store pending changes.
• Overcomplicating conflict resolution: Examiners prefer simple strategies (last-write-wins) over complex merge logic unless asked.

High-Score Answer Structure

1. Define the concept (e.g., "Delta sync minimizes bandwidth by transferring only changed data").
2. Draw a diagram (e.g., before/after sync state).
3. Give a Nepali example (e.g., "NTC uses delta sync for train schedules").
4. Compare with another method (e.g., "vs. full sync, which wastes bandwidth").
5. List pros/cons in a table.