Sync Engine: মূল ধারণা, ধরন ও কাজকর্ম প্রক্রিয়া

সিংক ইঞ্জিন কী?

Sync Engine — লোকাল ডেটাবেস এবং রিমোট API এর মধ্যে একটি আর্কিটেকচারাল লেয়ার যা উভয় দিকে তথ্য প্রবাহ পরিচালনা করে। এর কাজ: পরিবর্তন ট্র্যাক করা, সেগুলো সার্ভারে পাঠানো, সার্ভার থেকে পরিবর্তন গ্রহণ করা এবং কনফ্লিক্ট সমাধান করা। ব্যবহারকারী লোকাল তথ্যের সাথে যোগাযোগ করে, যখন Sync Engine একে সার্ভারের সাথে নির্বিঘ্নে সিঙ্ক্রোনাইজ করে।

Sync Engine বিল্ট-ইন (Firebase Firestore, Couchbase Lite, Realm) বা কাস্টম — নির্দিষ্ট ব্যবসায়িক যুক্তির জন্য লেখা হতে পারে। বিল্ট-ইন ইঞ্জিন প্রস্তুত offline-first কার্যকারিতা এবং কনফ্লিক্ট রেজল্যুশন অফার করে। কাস্টম ইঞ্জিন তথ্য ফরম্যাট, সিংক প্রোটোকল এবং কনফ্লিক্ট নীতির উপর সম্পূর্ণ নিয়ন্ত্রণ দেয়।

Sravana Karthik (2024) এর মতে, যিনি «Mobile Sync Engine Design Patterns» বইয়ের লেখক, একটি কাস্টম Sync Engine জটিল ব্যবসায়িক যুক্তি (অর্থ, স্বাস্থ্য, IoT) সম্পন্ন অ্যাপের জন্য যুক্তিযুক্ত যেখানে কাস্টম মার্জ নিয়ম অত্যন্ত গুরুত্বপূর্ণ। সাধারণ পরিদর্শন (নোটস, চ্যাট, ফিড) এর জন্য, বিল্ট-ইন Firestore বা Realm যথেষ্ট।

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

এই ইন্টারফেস Sync Engine এর সর্বনিম্ন চুক্তি বর্ণনা করে: pull (সার্ভার থেকে পরিবর্তন লোড করা), push (লোকাল পরিবর্তন পাঠানো), resolve (কনফ্লিক্ট সামলানো) এবং observe (সিংক অবস্থা পর্যবেক্ষণ)। এই অ্যাবস্ট্র্যাকশন প্রেজেন্টেশন লেয়ার পরিবর্তন ছাড়াই বাস্তবায়ন পরিবর্তনের অনুমতি দেয়।

সিঙ্ক্রোনাইজেশনের ধরন: পূর্ণ, ইনক্রিমেন্টাল ও পুশ

পূর্ণ সিংক (Full sync) — প্রতিটি সত্র সার্ভার থেকে সম্পূর্ণ ডেটাসেট লোড করে। বাস্তবায়ন করা সহজ, কিন্তু বড় পরিমাণের জন্য অগ্রহণীয়: প্রতিবার অ্যাপ খোলার সময় 10,000 রেকর্ড ডাউনলোড করা ট্রাফিক এবং ব্যাটারি খরচ করে। পূর্ণ সিংক বিরল হালনাগাদের সাথে রেফারেন্স ডেটা (দেশের তালিকা) এর জন্য যুক্তিযুক্ত।

ইনক্রিমেন্টাল সিংক — শুধু শেষ সিংকের পর পরিবর্তিত রেকর্ডগুলো স্থানান্তর করা হয়। সার্ভার প্রতিটি রেকর্ড বা সম্পূর্ণ সেটের জন্য শেষ পরিবর্তনের টাইমস্ট্যাম্প সংরক্ষণ করে। ক্লায়েন্ট lastSyncTimestamp পাঠায় এবং শুধু updated_at > সেই মান সম্পন্ন রেকর্ড গ্রহণ করে। Instagram Engineering (2024) এর মতে, ইনক্রিমেন্টাল সিংক পূর্ণ সিংকের তুলনায় তথ্য স্থানান্তরের পরিমাণ 97% হ্রাস করে।

পুশ সিংক (সার্ভার-শুরুকৃত) — সার্ভার নিজেই FCM (Firebase Cloud Messaging), WebSocket বা SSE (Server-Sent Events) এর মাধ্যমে ক্লায়েন্টকে সিংক করার প্রয়োজন জানায়। ক্লায়েন্ট পর্যায়িক পলিংয়ে সম্পদ নষ্ট করে না। পুশ সিংক রিয়াল-টাইম অ্যাপ: চ্যাট, নোটিফিকেশন, লাইকের জন্য সবচেয়ে উপযুক্ত পছন্দ। Google Firebase Firestore HTTP polling এ স্বচালিত ফলব্যাক সহ রিয়াল-টাইম সিংকের জন্য WebSocket ব্যবহার করে।

হাইব্রিড পদ্ধতি — ধরনের একটি সম্মিশ্রণ: অ্যাপ শুরতে বেসলাইন ডেটার জন্য পূর্ণ সিংক, তারপর হালনাগাদের জন্য ইনক্রিমেন্টাল সিংক, এবং জরুরী ঘটনাগুলোর জন্য FCM এর মাধ্যমে পুশ সিংক। এটি উভয় গতি এবং সম্পদ সংরক্ষণ নিশ্চিত করে।

ইনক্রিমেন্টাল সিংক — চেকপয়েন্ট ও ডেল্টা কীভাবে কাজ করে

চেকপয়েন্ট (Checkpoint) — একটি মান যা ক্লায়েন্ট সিংক সত্রগুলোর মধ্যে সংরক্ষণ করে। সাধারণত এটি শেষ সফলভাবে সিংক করা রেকর্ডের updated_at। পরবর্তী সিংকে, ক্লায়েন্ট চেকপয়েন্ট সার্ভারে পাঠায়, এবং সার্ভার চেকপয়েন্টের পর updated_at সম্পন্ন সকল রেকর্ড ফিরিয়ে দেয়। কার্সার-ভিত্তিক পেজিনেশন — একটি উন্নত সংস্করণ যেখানে সার্ভার ডেটার সাথে একটি কার্সার (পরবর্তী পৃষ্ঠার সঙ্কেতক) ফিরিয়ে দেয়।

ডেল্টা সিংক — সার্ভার বর্তমান তথ্য অবস্থা এবং ক্লায়েন্ট শেষ বার যে স্ন্যাপশট দেখেছিল তার মধ্যে পার্থক্য নির্ণয় করে। সকল রেকর্ড পাঠানোর পরিবর্তে, শুধু কাজগুলো (insert, update, delete) স্থানান্তর করা হয়। এটি বড় ডেটাসেটের জন্য বিশেষ কার্যকর যেখানে কয়েকটি রেকর্ড পরিবর্তিত হয়েছে। Google Drive API (2025) ফাইল ডেল্টা সিংকের জন্য pageToken সহ changes.list ব্যবহার করে।

«বিলম্বিত ডেল্টা» কৌশল — মোবাইল ক্লায়েন্টে, পরিবর্তনগুলো তাড়াতাড়ি পাঠানো হয় না বরং Offline Queue এ বাফার করা হয়। সীমায় পৌঁছলে (10 কাজ বা 30 সেকেন্ড), একটি ডেল্টা প্যাকেজ তৈরি করে সার্ভারে পাঠানো হয়। Dropbox Mobile Engineering (2024) এর মতে, ডেল্টা ব্যাচিং HTTP অনুরোধের সংখ্যা 65% এবং ব্যাটারি ব্যবহার 12% হ্রাস করেছে।

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

SyncCheckpoint দীর্ঘ তালিকার জন্য উভয় টাইমস্ট্যাম্প এবং পেজিনেশন কার্সার সংরক্ষণ করে। দুই-প্যারামিটার চেকপয়েন্ট নিশ্চিত করে যে বড় ডেটাসেট সিংক করার সময় কোন রেকর্ড বাদ পড়বে না বা ডুপ্লিকেট হবে না।

পুশ সিংক — WebSocket ও FCM এর মাধ্যমে তাড়াতাড়ি সিঙ্ক্রোনাইজেশন

WebSocket — ক্লায়েন্ট এবং সার্ভারের মধ্যে একটি স্থায়ী দ্বি-মুখী সংযোগ। সার্ভার ডেটা পরিবর্তনের সাথে সাথে হালনাগাদ পাঠায়। WebSocket রিয়াল-টাইম অ্যাপ: চ্যাট, স্ট্রিমিং, সহযোগিতামূলক কাজের জন্য সবচেয়ে উপযুক্ত। খামতা: সংযোগ ধরা রাখতে (heartbeat) ব্যাটারি এবং ট্রাফিক খরচ। Android এ OkHttp WebSocket এবং iOS এ URLSessionWebSocketTask — বিল্ট-ইন বাস্তবায়ন।

Firebase Cloud Messaging (FCM) — পুশ নোটিফিকেশন যা সার্ভার ব্যবহারকারীকে দেখানোর জন্য নয়, বরং সিঙ্ক্রোনাইজেশন চালু করার জন্য পাঠায়। একটি silent push (ডেটা মেসেজ) পেলে, অ্যাপ জাগে এবং Sync Engine শুরু করে। FCM এর একটি স্থায়ী সংযোগের প্রয়োজন নেই এবং বিরল নোটিফিকেশনের জন্য WebSocket এর চেয়ে বেশি সর্মথনীয়।

SSE (Server-Sent Events) — একটি এক-মুখী চ্যানেল যার মাধ্যমে সার্ভার ক্লায়েন্টে ইভেন্ট পাঠায়। বাস্তবায়নে WebSocket এর চেয়ে সহজ, কিন্তু দ্বি-মুখী যোগাযোগ সমর্থন করে না। EventSource API (JavaScript) এবং OkHttp SSE (Android) — জনপ্রিয় লাইব্রেরি। SSE নতুন ডেটার বিষয়ে বিজ্ঞপ্তির জন্য উপযুক্ত যখন ক্লায়েন্টকে একই চ্যানেলে ডেটা ফিরিয়ে পাঠানোর প্রয়োজন নেই।

WhatsApp Engineering (2024) এর মতে, তাদের Sync Engine সক্রিয় সত্রের জন্য WebSocket এবং পশ্চাতে অ্যাপ জাগানোর জন্য FCM এর সম্মিশ্রণ ব্যবহার করে: WebSocket 5 মিনিট নিষ্ক্রিয়তার পর সংযোগ বিচ্ছিন্ন হয়ে যায়, এবং পরবর্তী হালনাগাদ silent push এর মাধ্যমে পাঠানো হয়।

স্ন্যাপশট সিংক ও তথ্য ভার্সনিং

স্ন্যাপশট-ভিত্তিক সিংক — সার্ভার পর্যায়ক্রমে তথ্যের একটি পূর্ণ স্ন্যাপশট তৈরি করে এবং একটি ভার্সন নির্ধারণ করে। ক্লায়েন্ট বর্তমান ভার্সন সংখ্যা সংরক্ষণ করে। যদি এটি পুরানো হয় — একটি নতুন স্ন্যাপশট ডাউনলোড করে। এটি একটি সহজ এবং বিশ্বস্ত কৌশল, কিন্তু বারবার পরিবর্তনের জন্য অদক্ষ — প্রতিবার সম্পূর্ণ ডেটাসেট ডাউনলোড হয়।

প্রতি রেকর্ড ভার্সনিং — প্রতিটি রেকর্ডের একটি version ক্ষেত্র থাকে। সিংকের সময়, ক্লায়েন্ট সকল রেকর্ডের ভার্সন পাঠায়, এবং সার্ভার শুধু সেগুলোতে ফিরিয়ে দেয় যার ভার্সন পরিবর্তিত হয়েছে। এটি স্ন্যাপশট সিংকের চেয়ে বেশি দক্ষ, কিন্তু ক্লায়েন্টে ভার্সন সংরক্ষণ করা আবশ্যক। ভেক্টর ঘড়ি (Vector Clocks) — বিতরিত সিস্টেমের জন্য একটি উন্নত কৌশল যেখানে প্রতিটি নোড নিজের ভার্সন নির্ধারণ করে এবং কনফ্লিক্ট আংশিক ক্রমে সমাধান করা হয়।

ইনক্রিমেন্টাল ডিফ সহ স্ন্যাপশট — একটি হাইব্রিড পদ্ধতি: বিরল পূর্ণ স্ন্যাপশট (দিনে একবার) + তাদের মধ্যে ইনক্রিমেন্টাল সিংক। দীর্ঘ অনুপস্থিতির পর শুরতে, ক্লায়েন্ট একটি স্ন্যাপশট লোড করে, এবং বারবার সিংকের সময় — শুধু ডেল্টা। গিট-এর মতো পদ্ধতি — প্রতিটি ডেটা কমিটের একটি হ্যাশ থাকে, এবং ক্লায়েন্ট জানে কোন কমিট থেকে শুরু করতে হবে। এটি Couchbase Lite Sync Gateway (2024) এ বাস্তবায়িত এবং বিশ্বাসনীয়তার জন্য স্বর্ণালি মান।

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

ভার্সন সমাধানের নিয়ম: যদি ভার্সন মেলে — কোন পরিবর্তন নেই। যদি লোকাল ভার্সন নতুন হয় — লোকাল জয়ী। যদি সার্ভার ভার্সন নতুন হয় — সার্ভার জয়ী। শুধু যখন ভার্সন সমান কিন্তু তথ্য আলাদা — কনফ্লিক্ট রেজলভার ডাকা হয়। ভার্সন ফ্ল্যাগ সহ Last Write Wins — সর্বাধিক সহজ কিন্তু বিশ্বস্ত কৌশল।

মোবাইল অ্যাপের জন্য Sync Engine কীভাবে তৈরি করবেন

ধাপ 1: ডেটা মডেল সংজ্ঞায়িত করুণ — কোন সার্থক সিঙ্ক্রোনাইজ হয়, কত্তার পরিবর্তিত হয়, এবং তাদের আয়তন কত। প্রতিটি সার্থকের জন্য, কৌশল (ইনক্রিমেন্টাল / পূর্ণ / পুশ) এবং গ্রহণযোগ্য সিংক বিলম্ব নির্ধারণ করুণ।

ধাপ 2: একটি প্রোটোকল চেয়ে নিন — চেকপয়েন্ট সহ REST, সাবস্ক্রিপশন সহ GraphQL, বা দ্বি-মুখী স্ট্রিম সহ gRPC। GraphQL Subscriptions — আধুনিক অ্যাপের জন্য একটি জনপ্রিয় পছন্দ: pull এবং push উভয়ের জন্য একটি প্রোটোকল। Apollo Client (2025) ডিভাইস ক্যাশের মাধ্যমে অফলাইন সিংক সমর্থন করে।

ধাপ 3: একটি Offline Queue বাস্তবায়ন করুণ — আইডেম্পোটেন্সি কী সহ লোকাল পরিবর্তন সংরক্ষণ (নিবন্ধ «Offline Queue» দেখুন)। কিউ একটি বিশ্বস্ত Sync Engine এর ভিত্তি: এটি ছাড়া, সিঙ্ক্রোনাইজেশন পরিবর্তন বিতরণের গ্যারান্টি দেয় না।

ধাপ 4: একটি কনফ্লিক্ট রেজলভার চেয়ে নিন — সহজ ক্ষেত্রের জন্য LWW, সহযোগিতামূলক সম্পাদনার জন্য CRDT, ব্যবসায়িক যুক্তির জন্য কাস্টম মার্জ। নিয়ম: রেজলভারটি আইডেম্পোটেন্ট হতে হবে — একই কাজ পুনরায় প্রয়োগ করলে একই ফলাফল দেওয়া উচিত।

ধাপ 5: নিরীক্ষণ ও মেট্রিক্স — প্রতিটি সিংক লগ করুন: রেকর্ড সংখ্যা, বাস্তবায়ন সময়, কনফ্লিক্ট সংখ্যা, ত্রুটি। Firebase Crashlytics বা Sentry (2025) রিয়াল-টাইমে সিংক ত্রুটি ট্র্যাক করার অনুমতি দেয়।

Realm Team (2024) এর মতে, একটি সাধারণ মোবাইল অ্যাপ Sync Engine প্রতিদিন প্রতি ডিভাইস 100–500 সিঙ্ক্রোনাইজেশন প্রক্রিয়া করে, প্রতি সত্র গড়ে 50–200 KB ডেটা স্থানান্তর করে। প্রোটোকল অপ্টিমাইজেশন — JSON এর পরিবর্তে Protobuf কম্প্রেশন ব্যবহার — তথ্য স্থানান্তরের পরিমাণ আরও 40–60% হ্রাস করে।