Conflict Resolution: Strategies, Merging, and How It Works

What Is Conflict Resolution in Mobile Applications?

Conflict resolution is the process of bringing distributed data to a single consistent state after detecting conflicting changes. In centralized systems, conflicts do not occur: the server processes requests sequentially. In mobile applications with offline mode, the client modifies data locally and synchronizes with the server later. If two clients modified the same object, the server receives two versions with the same identifier but different content.

Conflicts are inevitable in loosely coupled replication (eventual consistency), where the system sacrifices instant consistency for availability and performance. According to researchers from Princeton University (Aggarwal et al., GEO paper, KDD 2024), systems with deferred replication demonstrate 28% higher performance under peak loads but require conflict resolution mechanisms for correct operation.

The resolution strategy is an algorithm that the system applies automatically when a conflict is detected. Different databases and frameworks implement different strategies: Firebase Realtime Database uses LWW, CouchDB adds Merge support, and Figma and Notion build their architecture on CRDT.

Why Conflicts Occur During Data Synchronization

The main cause of conflicts is simultaneous modification of the same resource by two or more clients working with a local copy of the data. A typical scenario: user A edits a task in Trello offline, while user B changes the description of the same task on another device. Both save their versions locally. When the devices go online, the server receives two different values for the same field.

Additional factors include network delays and network partitions. In distributed databases using the Raft or Paxos protocol, a conflict can occur if the cluster leader is temporarily unavailable and requests are processed by different nodes. According to the Amazon DynamoDB whitepaper (2025), about 0.3% of all write operations in scalable NoSQL systems result in detectable conflicts.

Conflicts also arise from incorrect data structures. If an application stores an operation counter or a participant list, two offline clients may perform operations that are sequentially incompatible. For example, client A adds an item to the end of a list while client B removes an item from the middle — during synchronization, the server does not know which action to apply first.

Last Write Wins — The Time-Based Winner Strategy

Last Write Wins (LWW) is a strategy where, among competing versions, the entry with the latest timestamp is selected. The system compares each version's timestamp and accepts the newer one, discarding the older one. This is a deterministic mechanism: given the same set of timestamps, the result is always the same, eliminating uncertainty. LWW is implemented in Firebase Realtime Database, Apache Cassandra, and Riak KV.

In mobile applications, LWW is particularly attractive due to its simplicity of implementation. The client does not need to analyze differences between versions, store change history, or show the user a selection dialog. The server makes the decision in milliseconds. However, LWW has a fundamental drawback — data loss. If two users simultaneously fill in different fields of a form, one version will be completely discarded.

Example of LWW operation in a mobile note-taking app with synchronization via REST API:

data class Note(
    val id: String,
    val title: String,
    val content: String,
    val updatedAt: Long
)

fun resolveWithLWW(
    local: Note,
    remote: Note
): Note {
    return if (local.updatedAt >= remote.updatedAt) local
    else remote
}

The resolveWithLWW function compares timestamps and returns the actual version. When timestamps are equal (which happens with high write frequency), the local version usually wins.

Merge Strategy — Merging Conflicting Versions

Merge Strategy is an approach where the system does not discard one of the versions entirely but attempts to combine changes from both into a consistent state. This is analogous to merging branches in Git: each conflict is resolved at the level of individual fields or operations. Merge strategies are divided into automatic (CRDT, OT) and manual (user selects the option).

The most well-known implementation is three-way merge. The system stores three versions: local, remote, and their common ancestor (the base version before divergence). If only one client changed a field, that change is accepted automatically. If both clients changed the same field — a conflict requiring resolution is recorded. CouchDB and PouchDB actively use this model for document synchronization.

Example of implementing three-way merge for a user profile:

data class Profile(
    val name: String,
    val email: String,
    val avatarUrl: String
)

fun threeWayMerge(
    base: Profile,
    local: Profile,
    remote: Profile
): Profile {
    return Profile(
        name = if (local.name != base.name) local.name
                else remote.name,
        email = if (local.email != base.email) local.email
                else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl) remote.avatarUrl
                    else local.avatarUrl
    )
}

Three-way merge is effective when the data structure is sufficiently stable. Problems arise when renaming fields, changing types, and performing array operations — in these cases, more complex logic is required.

CRDT — Conflict-Free Replicated Data Types

CRDT (Conflict-Free Replicated Data Type) is a mathematical model that guarantees data convergence without a central coordinator. CRDTs are designed so that all operations are commutative: the order of application does not affect the final result. This is achieved through algebraic properties: merging CRDTs always yields the same result regardless of the sequence of receiving changes.

Main types of CRDT include G-Counter (a counter supporting only increment), PN-Counter (a counter with increment and decrement), LWW-Register (a register with versioning), and OR-Set (a set with tracked addition and removal). Each type guarantees that merging two replicas will not produce conflicts. According to INRIA research (Marc Shapiro et al., 2024), CRDTs provide deterministic convergence for 95% of common data types.

Example of a G-Counter — a counter that can only be incremented:

class GCounter {
    private val counts = mutableMapOf<String, Int>()

    fun increment(nodeId: String) {
        counts[nodeId] = (counts[nodeId] ?: 0) + 1
    }

    fun value(): Int = counts.values.sum()

    fun merge(other: GCounter) {
        other.counts.forEach { (node, count) ->
            counts[node] = maxOf(counts[node] ?: 0, count)
        }
    }
}

GCounter guarantees correct merging because each node stores only its own counter, and merge takes the maximum per node. This is a classic example of a conflict-free structure used in decentralized systems.

How to Choose a Conflict Resolution Strategy

Choosing a strategy depends on the nature of the data and usage scenarios. LWW is optimal for applications where the latest version always has priority — news feeds, notifications, statuses. Merge Strategy is suitable for structured documents where each field is independent — user profiles, forms, configurations. CRDT is ideal for collaborative editing, lists, and counters in distributed systems.

When choosing a strategy, three factors are evaluated: data consistency, performance, and implementation complexity. LWW provides maximum performance and minimal complexity but may lose data. Merge offers high accuracy but requires a mechanism for detecting changes at the field level. CRDT guarantees mathematical correctness but imposes limitations on data types and metadata size.

In practice, a combined approach is often used: systems use LWW for metadata, Merge for document content, and CRDT for list structures. Firebase Firestore, for example, uses LWW for top-level fields and supports transactions for atomic updates. CouchDB uses Merge with change history storage. Figma and Notion build their architecture on CRDT for real-time multi-user editing.