Last Write Wins: یہ کیا ہے، طریقہ کار اور کام کرنے کا اصول

موبائل ڈیویلپمنٹ میں Last Write Wins کیا ہے؟

Last Write Wins (LWW) ہم آہنگی کے تنازعات کو حل کرنے کے لیے آخری تحریر کی حکمت عملی ہے۔ جب دو کلائنٹ ایک ہی ڈیٹا آبجیکٹ میں ترمیم کرتے ہیں، سرور دونوں ورژن وصول کرتا ہے اور بڑے ٹائم اسٹیمپ والے ورژن کا انتخاب کرتا ہے۔ LWW بہت سے تقسیم شدہ سسٹمز میں ڈیفالٹ حکمت عملی ہے: Firebase Realtime Database، Apache Cassandra، Riak KV اور DynamoDB آخری تحریر موڈ میں۔

موبائل ایپلیکیشنز میں، LWW تین وجوہات کی بنا پر پرکشش ہے: نفاذ کی سادگی، کم سے کم تاخیر اور صارف کے تعامل کی عدم موجودگی۔ ڈیویلپر کو پیچیدہmerge منطق لکھنے کی ضرورت نہیں اور صارف ورژن سلیکشن ڈائیلاگ نہیں دیکھتا۔ تاہم سادگی کی قیمت ممکنہ ڈیٹا نقصان ہے — جو تمام ایپلیکیشنز برداشت نہیں کر سکتیں۔

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 میں سرمایہ کاری کرنا مناسب ہے۔