Last Write Wins: What It Is, Mechanism and Operating Principle

What Is Last Write Wins in Mobile Development?

Last Write Wins (LWW) is a last-write strategy for resolving synchronization conflicts. When two clients modify the same data object, the server receives both versions and selects the one with the larger timestamp. LWW is the default strategy in many distributed systems: Firebase Realtime Database, Apache Cassandra, Riak KV, and DynamoDB in last-write mode.

In mobile applications, LWW is attractive for three reasons: simplicity of implementation, minimal latency, and no user interaction required. The developer does not need to write complex merge logic, and the user does not see version selection dialogs. However, the price for simplicity is potential data loss — which not all applications can afford.

According to research by Martin Kleppmann (author of “Designing Data-Intensive Applications”, O’Reilly, 2024), LWW is the most common strategy in production systems, used in approximately 70% of distributed applications where eventual consistency is acceptable. In 23% of cases, it leads to measurable user data loss.

How the LWW Mechanism Works

The LWW mechanism is based on comparing timestamps. Each data record is accompanied by a timestamp, which may be set by the client (client-side timestamp) or the server (server-side timestamp). When a conflict is detected, the system compares the timestamps of both versions and accepts the record with the larger value. The second version is either discarded or saved in the history for auditing.

Client-side timestamp has a drawback: clocks on user devices can be out of sync. If user A’s phone is 5 minutes behind and user B made changes, A’s record may be incorrectly considered newer after the clock is corrected. Therefore, production systems more often use server-side timestamps assigned by the server upon receiving data.

LWW logic with server-side timestamp:

data class SyncDocument(
    val id: String,
    val data: String,
    val serverTimestamp: Long
)

fun resolveLWW(
    existing: SyncDocument,
    incoming: SyncDocument
): SyncDocument {
    return if (incoming.serverTimestamp >= existing.serverTimestamp)
        incoming
    else
        existing
}

The resolveLWW function takes two documents and returns the one with the larger timestamp. When equal, the incoming document usually wins — this ensures that new data is not lost due to matching timestamps.

Advantages and Disadvantages of Last Write Wins

The main advantage of LWW is algorithmic simplicity. The strategy does not require storing version history, analyzing changes at the field level, or resolving composite conflicts. The server handles a conflict with one comparison operation, making LWW the fastest strategy. In Firebase Realtime Database, LWW processes up to 100 thousand conflicts per second on a single node.

The main disadvantage is data loss during independent changes to different fields. If user A changed the task name and user B changed the description, LWW discards one version entirely, even though both changes should be preserved. This is especially critical for forms, profiles, and configurations where every field matters.

Comparison of LWW with alternative strategies:

LWW Implementation Examples in Kotlin

Let’s consider an LWW implementation in the context of a mobile shopping list app where multiple family members can add and mark items offline. Each list item stores an ID, name, status, and the timestamp of the last update. During synchronization, LWW is applied to each item.

Basic list item model:

data class ShoppingItem(
    val id: String,
    val name: String,
    val isChecked: Boolean,
    val quantity: Int,
    val lastModified: Long
)

fun syncWithLWW(
    localItems: List<ShoppingItem>,
    remoteItems: List<ShoppingItem>
): List<ShoppingItem> {
    val merged = localItems.toMutableList()

    remoteItems.forEach { remote ->
        val index = merged.indexOfFirst { it.id == remote.id }
        if (index == -1) {
            merged.add(remote)
        } else {
            val local = merged[index]
            merged[index] = if (remote.lastModified >= local.lastModified)
                remote
            else
                local
        }
    }
    return merged
}

The syncWithLWW function merges local and remote lists: if an item exists on only one side, it is added; if on both sides, the newer version wins. This approach ensures deterministic synchronization for each individual item.

LWW vs Merge: Which to Choose

The choice between LWW and Merge is determined by the nature of data modification. If the application allows independent field changes (different users changing different fields of the same object), Merge Strategy preserves data more accurately. If changes are always atomic (a user changes the entire object), LWW is fully adequate and significantly simpler to implement.

In practice, many systems use a hybrid approach: LWW for meta-information and top-level fields, Merge for structured data. Firebase Firestore, for example, uses LWW for most operations but supports transactions with optimistic locking for atomic updates when the developer explicitly specifies that a field must not be lost during a conflict.

According to a survey of distributed systems developers (Stack Overflow Survey, 2025), 54% choose LWW for MVPs and prototypes, switching to Merge or CRDT during scaling. The key criterion is conflict frequency: if less than 1% of sessions result in conflicts, LWW is more than sufficient. If conflicts affect more than 5% of sessions, it is worth investing in Merge or CRDT.