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 е най-разпространената стратегия в производствените системи, използвана в приблизително 70% от разпределените приложения, където е приемлива евентуалната консистентност (eventual consistency). В 23% от случаите това довежда до измерима загуба на потребителски данни.

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

Механизъмът LWW се базира на сравнение на времеви марки. Всеки запис на данни е придружен от тимстъмп, който може да бъде зададен от клиента (client-side timestamp) или от сървъра (server-side timestamp). След откриване на конфликт, системата сравнява времевите марки на и двете версии и приема записа с по-голяма стойност. Втората версия или се отхвърля, или се запазва в историята за одит.

Client-side timestamp има недостатък: часовниците на устройствата на потребителите могат да бъдат десинхронизирани. Ако телефонът на потребител A изоства с 5 минути и потребител B направи промени, записът на A може да бъде грешно считан за по-нов след коригиране на часовника. Етозаради производствените системи по-често използват 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 приема два документа и върща този с по-голям тимстъмп. При равенство обикновено печели входящият документ — това гарантира, че новите данни не се загубват поради припадване на марките.

Предимства и недостатъци на Last Write Wins

Основното предимство на LWW е алгоритмичната простота. Стратегията не изисква съхранение на история на версиите, анализ на промените на ниво полета или разрешаване на сложни конфликти. Сървърът обработва конфликта в едина единична операция за сравнение, което прави LWW най-бързата стратегия. В Firebase Realtime Database LWW обработва до 100 хиляди конфликта на секунда на един възел.

Основният недостатък — загуба на данни при независими промени на различни полета. Ако потребител A промени името на задачата, а потребител B — описанието, 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.