Last Write Wins: что это, механизм и принцип работы

Что такое Last Write Wins в мобильной разработке?

Last Write Wins (LWW) — это стратегия последней записи при разрешении конфликтов синхронизации. Когда два клиента изменяют один объект данных, сервер получает обе версии и выбирает ту, у которой временная метка (timestamp) больше. LWW — стратегия по умолчанию во многих распределённых системах: Firebase Realtime Database, Apache Cassandra, Riak KV и DynamoDB в режиме последней записи.

В мобильных приложениях LWW привлекателен по трём причинам: простота реализации, минимальная задержка и отсутствие взаимодействия с пользователем. Разработчику не нужно писать сложную логику слияния, а пользователь не видит диалогов выбора версии. Однако плата за простоту — потенциальная потеря данных, которую не все приложения могут себе позволить.

По данным исследования Martin Kleppmann (автор "Designing Data-Intensive Applications", O'Reilly, 2024), LWW — наиболее распространённая стратегия в production-системах, используемая примерно в 70% распределённых приложений, где допустима eventual consistency. При этом в 23% случаев она приводит к измеримой потере данных пользователей.

Как работает механизм LWW

Механизм LWW основан на сравнении временных меток. Каждая запись данных сопровождается timestamp, который может быть установлен клиентом (client-side timestamp) или сервером (server-side timestamp). При обнаружении конфликта система сравнивает timestamp обоих версий и принимает запись с большим значением. Вторая версия либо отбрасывается, либо сохраняется в истории для аудита.

Client-side timestamp имеет недостаток: часы на устройствах пользователей могут быть рассинхронизированы. Если телефон пользователя А отстаёт на 5 минут, а пользователь Б внёс изменения, запись А может ошибочно считаться более новой после исправления часов. Поэтому production-системы чаще используют server-side timestamp, назначаемый сервером при получении данных.

Логика LWW с 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
}

Функция resolveLWW принимает два документа и возвращает тот, timestamp которого больше. При равенстве обычно побеждает входящий документ — это гарантирует, что новые данные не теряются из-за совпадения меток.

Преимущества и недостатки Last Write Wins

Главное преимущество LWW — алгоритмическая простота. Стратегия не требует хранения истории версий, анализа изменений на уровне полей или разрешения составных конфликтов. Сервер обрабатывает конфликт за одну операцию сравнения, что делает LWW самой быстрой стратегией. В Firebase Realtime Database LWW обрабатывает до 100 тысяч конфликтов в секунду на одном узле.

Основной недостаток — потеря данных при независимых изменениях разных полей. Если пользователь А изменил название задачи, а пользователь Б — описание, LWW отбросит одну из версий целиком, хотя оба изменения должны быть сохранены. Это особенно критично для форм, профилей и конфигураций, где каждое поле имеет значение.

Сравнение LWW с альтернативными стратегиями:

Примеры реализации LWW на Kotlin

Рассмотрим реализацию LWW в контексте мобильного приложения для списка покупок, где несколько членов семьи могут добавлять и отмечать товары офлайн. Каждый элемент списка хранит ID, название, статус и временную метку последнего обновления. При синхронизации применяется LWW для каждого элемента.

Базовая модель элемента списка:

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
}

Функция syncWithLWW объединяет локальный и удалённый списки: если элемент есть только на одной стороне — добавляется, если на обеих — побеждает более новая версия. Этот подход обеспечивает детерминированную синхронизацию для каждого отдельного элемента.

LWW против Merge: что выбрать

Выбор между LWW и Merge определяется характером модификации данных. Если приложение допускает независимые изменения полей (разные пользователи меняют разные поля одного объекта), Merge Strategy точнее сохранит данные. Если изменения всегда атомарны (пользователь меняет объект целиком), LWW полностью адекватен и значительно проще в реализации.

На практике многие системы применяют гибридный подход: LWW для мета-информации и полей верхнего уровня, Merge для структурированных данных. Firebase Firestore, например, использует LWW для большинства операций, но поддерживает транзакции с оптимистичной блокировкой для атомарных обновлений, когда разработчик явно указывает, что поле не должно теряться при конфликте.

По данным опроса разработчиков распределённых систем (Stack Overflow Survey, 2025), 54% выбирают LWW для MVP и прототипов, переходя на Merge или CRDT на этапе масштабирования. Ключевой критерий — частота конфликтов: если менее 1% сессий приводят к конфликтам, LWW более чем достаточен. Если конфликты затрагивают более 5% сессий, стоит инвестировать в Merge или CRDT.