Last Write Wins: nedir, mekanizma ve çalışma prensibi

Mobil geliştirmede Last Write Wins nedir?

Last Write Wins (LWW), senkronizasyon çakışmalarını çözmek için bir son yazma stratejisidir. İki istemci aynı veri nesnesini değiştirdiğinde, sunucu her iki sürümü de alır ve daha büyük zaman damgasına sahip olanı seçer. LWW, birçok dağıtık sistemde varsayılan stratejidir: Firebase Realtime Database, Apache Cassandra, Riak KV ve son yazma modunda DynamoDB.

Mobil uygulamalarda LWW üç nedenden dolayı çekicidir: uygulama basitliği, minimum gecikme ve kullanıcı etkileşimi gerektirmemesi. Geliştiricinin karmaşık birleştirme mantığı yazması gerekmez ve kullanıcı sürüm seçim diyalogları görmez. Ancak basitliğin bedeli olası veri kaybıdır — ki tüm uygulamalar bunu kaldıramaz.

Martin Kleppmann'ın araştırmasına göre (“Designing Data-Intensive Applications”, O’Reilly, 2024 yazarı), LWW, üretim sistemlerinde en yaygın stratejidir ve nihai tutarlılığın kabul edilebilir olduğu dağıtık uygulamaların yaklaşık %70'inde kullanılır. Vakaların %23'ünde ölçülebilir kullanıcı verisi kaybına yol açar.

LWW mekanizması nasıl çalışır

LWW mekanizması zaman damgalarının karşılaştırılmasına dayanır. Her veri kaydına, istemci (istemci tarafı zaman damgası) veya sunucu (sunucu tarafı zaman damgası) tarafından ayarlanabilen bir zaman damgası eşlik eder. Bir çakışma tespit edildiğinde, sistem her iki sürümün zaman damgalarını karşılaştırır ve daha büyük değere sahip kaydı kabul eder. İkinci sürüm ya atılır ya da denetim için geçmişe kaydedilir.

İstemci tarafı zaman damgasının bir dezavantajı vardır: kullanıcı cihazlarındaki saatler senkronize olmayabilir. Kullanıcı A'nın telefonu 5 dakika gerideyse ve kullanıcı B değişiklik yaptıysa, saat düzeltildikten sonra A'nın kaydı hatalı bir şekilde daha yeni olarak kabul edilebilir. Bu nedenle üretim sistemleri, veri alındığında sunucu tarafından atanan sunucu tarafı zaman damgalarını daha sık kullanır.

Sunucu tarafı zaman damgası ile LWW mantığı:

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 işlevi iki belge alır ve daha büyük zaman damgasına sahip olanı döndürür. Eşitlik durumunda, genellikle gelen belge kazanır — bu, zaman damgalarının çakışması nedeniyle yeni verilerin kaybolmamasını sağlar.

Last Write Wins'in avantajları ve dezavantajları

LWW'nin ana avantajı algoritmik basitliktir. Strateji, sürüm geçmişi depolaması, alan düzeyinde değişiklik analizi veya bileşik çakışma çözümü gerektirmez. Sunucu, tek bir karşılaştırma işlemiyle bir çakışmayı işler ve bu da LWW'yi en hızlı strateji yapar. Firebase Realtime Database'de LWW, tek bir düğümde saniyede 100 bine kadar çakışmayı işler.

Ana dezavantaj, farklı alanlardaki bağımsız değişiklikler sırasında veri kaybıdır. Kullanıcı A görev adını değiştirdiyse ve kullanıcı B açıklamayı değiştirdiyse, LWW bir sürümü tamamen atar, oysa her iki değişiklik de korunmalıdır. Bu, her alanın önemli olduğu formlar, profiller ve yapılandırmalar için özellikle kritiktir.

LWW'nin alternatif stratejilerle karşılaştırması:

Kotlin'de LWW uygulama örnekleri

Bir LWW uygulamasını, aile üyelerinin çevrimdışı olarak öğe ekleyip işaretleyebildiği bir mobil alışveriş listesi uygulaması bağlamında ele alalım. Her liste öğesi bir kimlik, ad, durum ve son güncellemenin zaman damgasını saklar. Senkronizasyon sırasında her öğeye LWW uygulanır.

Temel liste öğesi modeli:

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 işlevi yerel ve uzak listeleri birleştirir: öğe yalnızca bir tarafta varsa eklenir; her iki tarafta da varsa daha yeni sürüm kazanır. Bu yaklaşım, her bir öğe için deterministik senkronizasyon sağlar.

LWW vs Merge: ne seçilmeli

LWW ve Merge arasındaki seçim, veri değişikliğinin doğasına göre belirlenir. Uygulama bağımsız alan değişikliklerine izin veriyorsa (farklı kullanıcılar aynı nesnenin farklı alanlarını değiştiriyorsa), Merge Strategy verileri daha doğru şekilde korur. Değişiklikler her zaman atomikse (bir kullanıcı tüm nesneyi değiştiriyorsa), LWW tamamen yeterlidir ve uygulaması çok daha basittir.

Pratikte birçok sistem hibrit bir yaklaşım kullanır: meta-bilgi ve üst düzey alanlar için LWW, yapılandırılmış veriler için Merge. Örneğin Firebase Firestore, çoğu işlem için LWW kullanır ancak geliştiricinin bir alanın çakışma sırasında kaybolmaması gerektiğini açıkça belirttiği atomik güncellemeler için iyimser kilitlemeli işlemleri destekler.

Dağıtık sistem geliştiricileriyle yapılan bir ankete (Stack Overflow Survey, 2025) göre, %54'ü MVP ve prototipler için LWW'yi seçiyor ve ölçekleme sırasında Merge veya CRDT'ye geçiyor. Ana kriter çakışma sıklığıdır: oturumların %1'inden azı çakışmalara yol açıyorsa, LWW fazlasıyla yeterlidir. Çakışmalar oturumların %5'inden fazlasını etkiliyorsa, Merge veya CRDT'ye yatırım yapmaya değer.