Last Write Wins: qué es, mecanismo y principio de funcionamiento

¿Qué es Last Write Wins en el desarrollo móvil?

Last Write Wins (LWW) es una estrategia de última escritura para resolver conflictos de sincronización. Cuando dos clientes modifican el mismo objeto de datos, el servidor recibe ambas versiones y selecciona la que tiene la marca de tiempo más grande. LWW es la estrategia predeterminada en muchos sistemas distribuidos: Firebase Realtime Database, Apache Cassandra, Riak KV y DynamoDB en modo de última escritura.

En aplicaciones móviles, LWW es atractivo por tres razones: simplicidad de implementación, latencia mínima y ausencia de interacción con el usuario. El desarrollador no necesita escribir lógica de fusión compleja y el usuario no ve diálogos de selección de versión. Sin embargo, el precio de la simplicidad es la posible pérdida de datos, que no todas las aplicaciones pueden permitirse.

Según la investigación de Martin Kleppmann (autor de “Designing Data-Intensive Applications”, O’Reilly, 2024), LWW es la estrategia más común en sistemas de producción, utilizada en aproximadamente el 70% de las aplicaciones distribuidas donde la consistencia eventual es aceptable. En el 23% de los casos, provoca una pérdida medible de datos de usuario.

Cómo funciona el mecanismo LWW

El mecanismo LWW se basa en la comparación de marcas de tiempo. Cada registro de datos va acompañado de una marca de tiempo que puede ser establecida por el cliente (client-side timestamp) o por el servidor (server-side timestamp). Cuando se detecta un conflicto, el sistema compara las marcas de tiempo de ambas versiones y acepta el registro con el valor más grande. La segunda versión se descarta o se guarda en el historial para auditoría.

La marca de tiempo del lado del cliente tiene un inconveniente: los relojes de los dispositivos de los usuarios pueden estar desincronizados. Si el teléfono del usuario A está 5 minutos atrasado y el usuario B realizó cambios, el registro de A podría considerarse incorrectamente como más nuevo después de corregir el reloj. Por eso, los sistemas de producción usan más frecuentemente marcas de tiempo del lado del servidor, asignadas por el servidor al recibir los datos.

Lógica de LWW con marca de tiempo del servidor:

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
}

La función resolveLWW recibe dos documentos y devuelve el que tiene la marca de tiempo más grande. En caso de igualdad, generalmente gana el documento entrante, lo que garantiza que los nuevos datos no se pierdan por coincidencia de marcas.

Ventajas y desventajas de Last Write Wins

La principal ventaja de LWW es la simplicidad algorítmica. La estrategia no requiere almacenar el historial de versiones, analizar cambios a nivel de campo ni resolver conflictos compuestos. El servidor maneja un conflicto con una sola operación de comparación, lo que convierte a LWW en la estrategia más rápida. En Firebase Realtime Database, LWW procesa hasta 100 mil conflictos por segundo en un solo nodo.

La principal desventaja es la pérdida de datos durante cambios independientes en diferentes campos. Si el usuario A cambió el nombre de la tarea y el usuario B cambió la descripción, LWW descarta una versión por completo, aunque ambos cambios deberían conservarse. Esto es especialmente crítico para formularios, perfiles y configuraciones donde cada campo importa.

Comparación de LWW con estrategias alternativas:

Ejemplos de implementación de LWW en Kotlin

Consideremos una implementación de LWW en el contexto de una aplicación móvil de lista de compras donde varios miembros de la familia pueden agregar y marcar artículos sin conexión. Cada elemento de la lista almacena un ID, nombre, estado y la marca de tiempo de la última actualización. Durante la sincronización, se aplica LWW a cada elemento.

Modelo básico del elemento de lista:

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
}

La función syncWithLWW combina las listas local y remota: si un elemento existe solo en un lado, se agrega; si existe en ambos, gana la versión más nueva. Este enfoque garantiza una sincronización determinista para cada elemento individual.

LWW vs Merge: qué elegir

La elección entre LWW y Merge está determinada por la naturaleza de la modificación de datos. Si la aplicación permite cambios independientes en los campos (diferentes usuarios modifican diferentes campos del mismo objeto), Merge Strategy conserva los datos con mayor precisión. Si los cambios son siempre atómicos (un usuario cambia el objeto completo), LWW es completamente adecuado y mucho más simple de implementar.

En la práctica, muchos sistemas utilizan un enfoque híbrido: LWW para metainformación y campos de nivel superior, Merge para datos estructurados. Firebase Firestore, por ejemplo, usa LWW para la mayoría de las operaciones, pero admite transacciones con bloqueo optimista para actualizaciones atómicas cuando el desarrollador especifica explícitamente que un campo no debe perderse durante un conflicto.

Según una encuesta a desarrolladores de sistemas distribuidos (Stack Overflow Survey, 2025), el 54% elige LWW para MVPs y prototipos, migrando a Merge o CRDT durante la escalabilidad. El criterio clave es la frecuencia de conflictos: si menos del 1% de las sesiones resultan en conflictos, LWW es más que suficiente. Si los conflictos afectan a más del 5% de las sesiones, vale la pena invertir en Merge o CRDT.