Last Write Wins: यह क्या है, तंत्र और कार्य सिद्धांत

मोबाइल डेवलपमेंट में Last Write Wins क्या है?

Last Write Wins (LWW) सिंक्रनाइज़ेशन संघर्षों को हल करने की एक अंतिम लेखन रणनीति है। जब दो क्लाइंट एक ही डेटा ऑब्जेक्ट को संशोधित करते हैं, तो सर्वर दोनों संस्करण प्राप्त करता है और बड़े टाइमस्टैम्प वाले संस्करण का चयन करता है। LWW कई वितरित सिस्टमों में डिफ़ॉल्ट रणनीति है: Firebase Realtime Database, Apache Cassandra, Riak KV और अंतिम लेखन मोड में DynamoDB।

मोबाइल एप्लिकेशन में, LWW तीन कारणों से आकर्षक है: कार्यान्वयन की सरलता, न्यूनतम विलंबता और उपयोगकर्ता संपर्क की अनुपस्थिति। डेवलपर को जटिल मर्ज लॉजिक लिखने की आवश्यकता नहीं है और उपयोगकर्ता संस्करण चयन संवाद नहीं देखता है। हालाँकि, सरलता की कीमत संभावित डेटा हानि है — जिसे सभी एप्लिकेशन वहन नहीं कर सकते।

Martin Kleppmann (उ “Designing Data-Intensive Applications”, O’Reilly, 2024 के लेखक) के शोध के अनुसार, LWW उत्पादन सिस्टम में सबसे आम रणनीति है, जो लगभग 70% वितरित एप्लिकेशन में उपयोग की जाती है जहाँ अंततः संगति स्वीकार्य है। 23% मामलों में, यह उपयोगकर्ता डेटा की मापने योग्य हानि की ओर ले जाती है।

LWW तंत्र कैसे काम करता है

LWW तंत्र टाइमस्टैम्प की तुलना पर आधारित है। प्रत्येक डेटा रिकॉर्ड के साथ एक टाइमस्टैम्प होता है जिसे क्लाइंट (क्लाइंट-साइड टाइमस्टैम्प) या सर्वर (सर्वर-साइड टाइमस्टैम्प) द्वारा सेट किया जा सकता है। जब कोई संघर्ष पाया जाता है, तो सिस्टम दोनों संस्करणों के टाइमस्टैम्प की तुलना करता है और बड़े मान वाले रिकॉर्ड को स्वीकार करता है। दूसरा संस्करण या तो छोड़ दिया जाता है या ऑडिट के लिए इतिहास में सहेजा जाता है।

क्लाइंट-साइड टाइमस्टैम्प में एक कमी है: उपयोगकर्ताओं के डिवाइसों पर घड़ियाँ सिंक से बाहर हो सकती हैं। यदि उपयोगकर्ता A का फ़ोन 5 मिनट पीछे है और उपयोगकर्ता B ने बदलाव किए, तो घड़ी ठीक होने के बाद A का रिकॉर्ड गलती से नया माना जा सकता है। इसलिए उत्पादन सिस्टम अक्सर सर्वर-साइड टाइमस्टैम्प का उपयोग करते हैं जो डेटा प्राप्त करने पर सर्वर द्वारा निर्दिष्ट किए जाते हैं।

सर्वर-साइड टाइमस्टैम्प के साथ LWW तर्क:

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 की वैकल्पिक रणनीतियों से तुलना:

Kotlin में LWW कार्यान्वयन उदाहरण

आइए एक मोबाइल शॉपिंग लिस्ट एप्लिकेशन के संदर्भ में 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% MVP और प्रोटोटाइप के लिए LWW चुनते हैं, स्केलिंग के दौरान Merge या CRDT पर स्विच करते हैं। मुख्य मानदंड संघर्ष आवृत्ति है: यदि 1% से कम सत्र संघर्षों की ओर ले जाते हैं, तो LWW पर्याप्त से अधिक है। यदि संघर्ष 5% से अधिक सत्रों को प्रभावित करते हैं, तो Merge या CRDT में निवेश करना उचित है।