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-তে বিনিয়োগ করা মূল্যবান।