Sync Engine: کلیدی تصورات، اقسام اور کام کرنے کے میکانزم

سنک انجن کیا ہے؟

Sync Engine — مقامی ڈیٹا بیس اور ریموٹ API کے درمیان ایک آرکیٹیکچرل پرت ہے جو دونوں سمتوں میں ڈیٹا کے بہاؤ کو منظم کرتی ہے۔ اس کے کام: تبدیلیوں کو ٹریک کرنا، انہیں سرور پر بھیجنا، سرور سے تبدیلیاں وصول کرنا اور تنازعات کو حل کرنا۔ صارف مقامی ڈیٹا کے ساتھ تعامل کرتا ہے، جبکہ Sync Engine اسے سرور کے ساتھ بغیر کسی رکاوٹ کے سنکرونائز کرتا ہے۔

Sync Engine بلٹ ان (Firebase Firestore، Couchbase Lite، Realm) یا کسٹم — مخصوص کاروباری منطق کے لیے لکھا ہوا ہو سکتا ہے۔ بلٹ ان انجن تیار شدہ offline-first فعالیت اور تنازعات کا حل پیش کرتے ہیں۔ کسٹم انجن ڈیٹا فارمیٹ، سنک پروٹوکول اور تنازعات کی پالیسی پر مکمل کنٹرول دیتے ہیں۔

سروانا کارتک (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 کے ذریعے پش سنک۔ یہ رفتار اور وسائل کی بچت دونوں فراہم کرتا ہے۔

انکریمنٹل سنک — چیک پوائنٹس اور ڈیلٹا کیسے کام کرتے ہیں

چیک پوائنٹ — ایک قدر جو کلائنٹ سنک سیشنز کے درمیان محفوظ کرتا ہے۔ عام طور پر یہ آخری کامیابی سے سنک کردہ ریکارڈ کا updated_at ہوتا ہے۔ اگلی سنک پر، کلائنٹ چیک پوائنٹ سرور کو بھیجتا ہے، اور سرور چیک پوائنٹ کے بعد updated_at والے تمام ریکارڈ واپس کرتا ہے۔ کرسر پر مبنی پیجینیشن — ایک جدید ورژن جہاں سرور ڈیٹا کے ساتھ ایک کرسر (اگلے صفحے کی طرف اشارہ کرنے والا) واپس کرتا ہے۔

ڈیلٹا سنک — سرور ڈیٹا کی موجودہ حالت اور اس اسنیپ شاٹ کے درمیان فرق کا حساب لگاتا ہے جو کلائنٹ نے آخری بار دیکھا تھا۔ تمام ریکارڈ بھیجنے کے بجائے صرف آپریشنز (insert، update، delete) منتقل کیے جاتے ہیں۔ یہ بڑے ڈیٹا سیٹس کے لیے خاص طور پر مؤثر ہے جہاں صرف چند ریکارڈ تبدیل ہوئے ہوں۔ Google Drive API (2025) فائل ڈیلٹا سنک کے لیے pageToken کے ساتھ changes.list استعمال کرتا ہے۔

«التوا والے ڈیلٹا» کی حکمت عملی — موبائل کلائنٹ پر، تبدیلیاں فوراً نہیں بھیجی جاتیں بلکہ آف لائن قطار میں بفر کی جاتی ہیں۔ جب حد (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 ریئل ٹائم ایپلیکیشنز: چیٹ، سٹریمنگ، تعاون پر مبنی کام کے لیے بہترین ہے۔ نقصان: کنکشن برقرار رکھنے (ہارٹ بیٹ) کے لیے بیٹری اور ٹریفک خرچ۔ Android پر OkHttp WebSocket اور iOS پر URLSessionWebSocketTask — بلٹ ان نفاذ۔

Firebase Cloud Messaging (FCM) — پش نوٹیفکیشنز جو سرور صارف کو دکھانے کے لیے نہیں بلکہ سنکرونائزیشن شروع کرنے کے لیے بھیجتا ہے۔ سائلنٹ پش (ڈیٹا میسج) موصول ہونے پر، ایپ جاگتی ہے اور 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 منٹ کی غیرفعالیت کے بعد منقطع ہو جاتا ہے، اور بعد کی اپ ڈیٹس سائلنٹ پش کے ذریعے پہنچائی جاتی ہیں۔

اسنیپ شاٹ سنک اور ڈیٹا ورژننگ

اسنیپ شاٹ پر مبنی سنک — سرور وقتاً فوقتاً ڈیٹا کا مکمل اسنیپ شاٹ بناتا ہے اور اسے ایک ورژن تفویض کرتا ہے۔ کلائنٹ موجودہ ورژن نمبر محفوظ کرتا ہے۔ اگر یہ پرانا ہو — نیا اسنیپ شاٹ ڈاؤن لوڈ کرتا ہے۔ یہ ایک سادہ اور قابل اعتماد حکمت عملی ہے، لیکن بار بار تبدیلیوں کے لیے غیر موثر — ہر بار ڈیٹا کا مکمل سیٹ ڈاؤن لوڈ ہوتا ہے۔

ریکارڈ کی سطح پر ورژننگ — ہر ریکارڈ میں version فیلڈ ہوتا ہے۔ سنک کے دوران، کلائنٹ تمام ریکارڈز کے ورژن بھیجتا ہے، اور سرور صرف انہیں واپس کرتا ہے جن کا ورژن تبدیل ہوا ہے۔ یہ اسنیپ شاٹ سنک سے زیادہ موثر ہے، لیکن کلائنٹ پر ورژن محفوظ کرنے کی ضرورت ہے۔ ویکٹر کلاکس — تقسیم شدہ نظاموں کے لیے ایک جدید تکنیک جہاں ہر نوڈ اپنا ورژن تفویض کرتا ہے اور تنازعات جزوی ترتیب سے حل کیے جاتے ہیں۔

انکریمنٹل ڈیف کے ساتھ اسنیپ شاٹ — ایک ہائبرڈ طریقہ: نایاب مکمل اسنیپ شاٹ (دن میں ایک بار) + ان کے درمیان انکریمنٹل سنک۔ طویل غیر حاضری کے بعد شروع کرتے وقت، کلائنٹ ایک اسنیپ شاٹ لوڈ کرتا ہے، اور بار بار سنک کے دوران — صرف ڈیلٹا۔ Git جیسا طریقہ — ڈیٹا کے ہر کمٹ میں ایک ہیش ہوتا ہے، اور کلائنٹ جانتا ہے کہ کس کمٹ سے شروع کرنا ہے۔ یہ 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، Subscriptions کے ساتھ GraphQL یا دو طرفہ سٹریم کے ساتھ gRPC۔ GraphQL Subscriptions — جدید ایپلیکیشنز کے لیے ایک مقبول انتخاب: pull اور push دونوں کے لیے ایک پروٹوکول۔ Apollo Client (2025) ڈیوائس کیش کے ذریعے آف لائن سنک کو سپورٹ کرتا ہے۔

مرحلہ 3: آف لائن قطار نافذ کریں — idempotency keys کے ساتھ مقامی تبدیلیوں کا ذخیرہ (مضمون «Offline Queue» دیکھیں)۔ قطار ایک قابل اعتماد Sync Engine کی بنیاد ہے: اس کے بغیر، سنکرونائزیشن تبدیلیوں کی ترسیل کی ضمانت نہیں دیتی۔

مرحلہ 4: تنازع حل کرنے والا منتخب کریں — سادہ معاملات کے لیے LWW، مشترکہ ترمیم کے لیے CRDT، کاروباری منطق کے لیے کسٹم انضمام۔ قاعدہ: حل کرنے والا idempotent ہونا چاہیے — ایک ہی آپریشن کو دوبارہ لاگو کرنے سے وہی نتیجہ آنا چاہیے۔

مرحلہ 5: نگرانی اور میٹرکس — ہر سنک کو لاگ کریں: ریکارڈ کی تعداد، عملدرآمد کا وقت، تنازعات کی تعداد، خرابیاں۔ Firebase Crashlytics یا Sentry (2025) ریئل ٹائم میں سنک کی خرابیوں کو ٹریک کرنے کی اجازت دیتے ہیں۔

Realm Team (2024) کے مطابق، ایک عام موبائل ایپ Sync Engine فی ڈیوائس روزانہ 100–500 سنکرونائزیشنز پر کارروائی کرتا ہے، فی سیشن اوسطاً 50–200 KB ڈیٹا منتقل کرتا ہے۔ پروٹوکول آپٹیمائزیشن — JSON کے بجائے Protobuf کمپریشن استعمال کرنا — ڈیٹا کی منتقلی کے حجم کو مزید 40–60% کم کرتا ہے۔