Last Write Wins : ce que c'est, mécanisme et principe de fonctionnement

Qu'est-ce que Last Write Wins dans le développement mobile ?

Last Write Wins (LWW) est une stratégie de dernière écriture pour résoudre les conflits de synchronisation. Lorsque deux clients modifient le même objet de données, le serveur reçoit les deux versions et sélectionne celle avec le timestamp le plus grand. LWW est la stratégie par défaut dans de nombreux systèmes distribués : Firebase Realtime Database, Apache Cassandra, Riak KV et DynamoDB en mode dernière écriture.

Dans les applications mobiles, LWW est attractif pour trois raisons : simplicité d'implémentation, latence minimale et absence d'interaction utilisateur. Le développeur n'a pas besoin d'écrire de logique de fusion complexe et l'utilisateur ne voit pas de dialogues de sélection de version. Cependant, le prix de la simplicité est une perte de données potentielle — que toutes les applications ne peuvent pas se permettre.

Selon les recherches de Martin Kleppmann (auteur de « Designing Data-Intensive Applications », O’Reilly, 2024), LWW est la stratégie la plus courante dans les systèmes de production, utilisée dans environ 70% des applications distribuées où la cohérence éventuelle est acceptable. Dans 23% des cas, elle entraîne une perte mesurable de données utilisateur.

Comment fonctionne le mécanisme LWW

Le mécanisme LWW repose sur la comparaison des timestamps. Chaque enregistrement de données est accompagné d'un timestamp qui peut être défini par le client (client-side timestamp) ou par le serveur (server-side timestamp). Lorsqu'un conflit est détecté, le système compare les timestamps des deux versions et accepte l'enregistrement avec la valeur la plus grande. La deuxième version est soit abandonnée, soit conservée dans l'historique pour audit.

Le timestamp côté client présente un inconvénient : les horloges des appareils des utilisateurs peuvent être désynchronisées. Si le téléphone de l'utilisateur A a 5 minutes de retard et que l'utilisateur B a effectué des modifications, l'enregistrement de A pourrait être considéré à tort comme plus récent après la correction de l'horloge. C'est pourquoi les systèmes de production utilisent plus souvent des timestamps côté serveur, attribués par le serveur à la réception des données.

Logique LWW avec timestamp côté serveur :

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 fonction resolveLWW prend deux documents et renvoie celui avec le timestamp le plus grand. En cas d'égalité, le document entrant gagne généralement — cela garantit que les nouvelles données ne sont pas perdues en raison de la coïncidence des timestamps.

Avantages et inconvénients de Last Write Wins

Le principal avantage de LWW est la simplicité algorithmique. La stratégie ne nécessite pas de stockage d'historique de versions, d'analyse des modifications au niveau des champs ou de résolution de conflits composites. Le serveur traite un conflit avec une seule opération de comparaison, faisant de LWW la stratégie la plus rapide. Dans Firebase Realtime Database, LWW traite jusqu'à 100 000 conflits par seconde sur un seul nœud.

Le principal inconvénient est la perte de données lors de modifications indépendantes de différents champs. Si l'utilisateur A a modifié le nom de la tâche et l'utilisateur B a modifié la description, LWW abandonne une version entièrement, alors que les deux modifications devraient être conservées. C'est particulièrement critique pour les formulaires, les profils et les configurations où chaque champ a de l'importance.

Comparaison de LWW avec les stratégies alternatives :

Exemples d'implémentation de LWW en Kotlin

Considérons une implémentation de LWW dans le contexte d'une application mobile de liste de courses où plusieurs membres de la famille peuvent ajouter et marquer des articles hors ligne. Chaque élément de liste stocke un ID, un nom, un statut et le timestamp de la dernière mise à jour. Pendant la synchronisation, LWW est appliqué à chaque élément.

Modèle de base d'un élément de liste :

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 fonction syncWithLWW fusionne les listes locale et distante : si un élément existe d'un seul côté, il est ajouté ; s'il existe des deux côtés, la version la plus récente gagne. Cette approche garantit une synchronisation déterministe pour chaque élément individuel.

LWW vs Merge : que choisir

Le choix entre LWW et Merge est déterminé par la nature de la modification des données. Si l'application permet des modifications indépendantes de champs (différents utilisateurs modifiant différents champs du même objet), Merge Strategy préserve les données plus précisément. Si les modifications sont toujours atomiques (un utilisateur modifie l'objet entier), LWW est tout à fait adéquat et significativement plus simple à implémenter.

En pratique, de nombreux systèmes utilisent une approche hybride : LWW pour les métadonnées et les champs de niveau supérieur, Merge pour les données structurées. Firebase Firestore, par exemple, utilise LWW pour la plupart des opérations, mais prend en charge les transactions avec verrouillage optimiste pour les mises à jour atomiques lorsque le développeur spécifie explicitement qu'un champ ne doit pas être perdu lors d'un conflit.

Selon une enquête auprès des développeurs de systèmes distribués (Stack Overflow Survey, 2025), 54% choisissent LWW pour les MVP et prototypes, passant à Merge ou CRDT lors de la mise à l'échelle. Le critère clé est la fréquence des conflits : si moins de 1% des sessions aboutissent à des conflits, LWW est plus que suffisant. Si les conflits affectent plus de 5% des sessions, il vaut la peine d'investir dans Merge ou CRDT.