Offline Queue: اصول، حکمت عملی اور کام کرنے کے میکانزم

آف لائن قطار کیا ہے؟

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

ایک منظرنامے کا تصور کریں: میسنجر صارف انٹرنیٹ کے بغیر سب وے میں پیغامات ٹائپ کر رہا ہے۔ «بھیجیں» کا ہر ٹیپ Offline Queue میں شامل ہو جاتا ہے۔ جب ٹرین سرنگ سے باہر نکلتی ہے اور نیٹ ورک دستیاب ہوتا ہے، تمام پیغامات خود بخود بھیج دیے جاتے ہیں۔ صارف کا تجربہ — ہموار: اسے پتہ نہیں چلتا کہ وہ آف لائن تھا، سوائے بھیجنے میں ہلکی تاخیر کے۔

Uber Engineering (2024) کے مطابق، ان کی آف لائن قطار خراب کنکشن والے علاقوں میں روزانہ 20 لاکھ سے زیادہ آپریشنز پروسیس کرتی ہے۔ قطار FIFO ترتیب اور exactly-once ضمانتی ترسیل کے میکانزم کے ساتھ Room مقامی اسٹوریج استعمال کرتی ہے۔

data class QueuedOperation(
    val id: String,
    val type: OperationType,
    val endpoint: String,
    val payload: String,
    val timestamp: Long,
    val retryCount: Int = 0,
    val idempotencyKey: String
)

ہر آپریشن میں دوبارہ بھیجنے کے لیے تمام ضروری ڈیٹا ہوتا ہے: اینڈ پوائنٹ، درخواست کا باڈی، ٹائم اسٹیمپ اور idempotencyKey۔ Room ڈیٹابیس ایپلیکیشن دوبارہ شروع ہونے اور OS کریش ہونے پر قطار کے استحکام کی ضمانت دیتا ہے۔

موبائل ایپ میں آپریشن قطار کیوں ضروری ہے

ترسیل کی ضمانت — قطار کا بنیادی مقصد۔ صارف کو یقین ہونا چاہیے کہ اس کا عمل (پیغام بھیجنا، پسند کرنا، آرڈر دینا) مکمل ہو جائے گا، چاہے نیٹ ورک اس وقت دستیاب نہ ہو۔ ریٹری میکانزم کے ساتھ Offline Queue حتمی ترسیل کی ضمانت دیتی ہے۔

خراب کنکشن کے حالات میں بہتر UX — GSMA Mobile Economy Report (2025) کے مطابق، دنیا بھر میں تقریباً 40% موبائل صارفین کے پاس غیر مستحکم انٹرنیٹ کنکشن ہیں۔ Offline Queue ایپ کو سب وے، لفٹوں، دور دراز علاقوں میں استعمال کے قابل بناتی ہے — ہر جہاں کنیکٹیویٹی وقفے وقفے سے ہوتی ہے۔

ڈیٹا کے نقصان میں کمی — قطار کے بغیر، آف لائن کیے گئے تمام اعمال ضائع ہو جاتے ہیں۔ صارف ایک لمبا فارم بھر سکتا ہے، «جمع کریں» پر ٹیپ کر سکتا ہے اور نیٹ ورک کی غلطی دیکھ سکتا ہے — سارا ان پٹ ضائع ہو جاتا ہے۔ Offline Queue ڈیٹا محفوظ کرتی ہے اور پہلے موقع پر بھیجتی ہے۔ Google Docs میں آٹو سیو دستاویزات کے لیے آف لائن قطار کی ایک کلاسک مثال ہے۔

غیر متزامن سنکرونائزیشن — قطار ایپلیکیشن کو بھیجنے کے دوران UI کو مسدود کرنے سے روکتی ہے۔ صارف کام جاری رکھتا ہے جبکہ سنک مینیجر پس منظر میں قطار کو پروسیس کرتا ہے۔ یہ ری ایکٹو آرکیٹیکچر کے اصولوں پر عمل کرتا ہے اور انٹرفیس کی ردعمل کو بہتر بناتا ہے۔

آف لائن قطار کا آرکیٹیکچر: ذخیرہ اور پروسیسنگ

قطار کی تین پرتیں: ذخیرہ (استحکام)، شیڈیولر (scheduler) اور عمل درآمد کنندہ۔ ذخیرہ — QueuedOperation ٹیبل کے ساتھ Room۔ شیڈیولر — WorkManager (Android) یا BGTaskScheduler (iOS) جو نیٹ ورک دستیاب ہونے پر سنکرونائزیشن شروع کرتا ہے۔ عمل درآمد کنندہ — ایک ترتیبی FIFO تکرار کنندہ جو ایک ایک کر کے آپریشن بھیجتا ہے۔

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

انضمام کی حکمت عملی — اگر قطار میں CREATE ہے اور فوراً بعد اسی آبجیکٹ کا DELETE ہے، تو دونوں آپریشنز کو بغیر بھیجے ہٹایا جا سکتا ہے: حتمی حالت یہ ہے کہ آبجیکٹ بنایا نہیں گیا۔ اسی طرح، CREATE + UPDATE کو تازہ ترین ڈیٹا کے ساتھ ایک CREATE میں ضم کیا جا سکتا ہے۔ قطار کی اصلاح HTTP درخواستوں کی تعداد کم کرتی ہے اور سنکرونائزیشن کو تیز کرتی ہے۔

Android Developers (2025) کے مطابق، Android پر Offline Queue کو سنبھالنے کا ترجیحی طریقہ WorkManager ہے: یہ ڈیوائس ریسٹارٹ کے بعد بھی عمل درآمد کی ضمانت دیتا ہے، نیٹ ورک کی پابندیوں کو سپورٹ کرتا ہے، اور NetworkType.CONNECTED کے ذریعے ریٹری پالیسیاں ترتیب دینے کی اجازت دیتا ہے۔

class SyncWorker(
    private val context: Context,
    private val params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result = runCatching {
        queueRepository.processNextBatch(batchSize = 10)
        Result.success()
    }.getOrDefault(Result.retry())
}

CoroutineWorker آپریشنز کے بیچوں کو پروسیس کرتا ہے اور ناکامی پر Result.retry() لوٹاتا ہے — WorkManager خود بخود ایکسپونینشل بیک آف کے ساتھ دوبارہ کوشش کرتا ہے۔ Android پر قابل بھروسہ Offline Queue حاصل کرنے کا یہ سب سے آسان طریقہ ہے۔

دوبارہ کوشش کی حکمت عملی: exponential backoff اور ریٹری پالیسی

Exponential Backoff — بڑھتے ہوئے وقفوں کے ساتھ ایک معیاری دوبارہ کوشش کی حکمت عملی: 2 سیکنڈ، 4 سیکنڈ، 8 سیکنڈ، 16 سیکنڈ اور اسی طرح زیادہ سے زیادہ حد تک۔ یہ سرور پر بار بار اوورلوڈ کو روکتا ہے اگر وہ عارضی طور پر دستیاب نہ ہو۔ Java لائبریری Resilience4j (2024) قابل ترتیب بیک آف کے ساتھ تیار Retry نفاذ فراہم کرتی ہے۔

زیادہ سے زیادہ کوششوں کی تعداد — ایک اہم پیرامیٹر۔ اگر 5–10 کوششوں کے بعد آپریشن ناکام ہو جائے تو مزید کوششیں فضول اور بے کار ہیں۔ ایک dead letter queue تجویز کی جاتی ہے: کوششیں ختم ہونے کے بعد آپریشن کو دستی تجزیہ کے لیے علیحدہ ٹیبل میں منتقل کیا جاتا ہے۔ Microsoft Patterns & Practices (2024) کے مطابق، dead letter queue سنکرونائزیشن کے مسائل کی ڈیبگنگ کو آسان بناتی ہے اور خراب آپریشنز کو قطار کو مسدود کرنے سے روکتی ہے۔

Jitter — بے ترتیب تغیر — بیک آف وقفہ میں بے ترتیب نمبر شامل کرنا۔ اگر ایک ہزار ڈیوائسز بیک وقت نیٹ ورک بحال کر لیں تو وہ سب ایک ساتھ سنکرونائز ہونا شروع ہو جاتی ہیں۔ Jitter انہیں وقت میں پھیلا دیتا ہے، سرور پر Cache Stampede کو روکتا ہے۔ مکمل jitter: delay = random(0, backoff) — AWS (2024) کی طرف سے API کلائنٹس کے لیے تجویز کردہ۔

تصادم کا حل: ڈیٹا کے تصادم کو کیسے حل کریں

Last Write Wins (LWW) — سب سے آسان حکمت عملی: تصادم کی صورت میں، بعد کے ٹائم اسٹیمپ والا آپریشن جیتتا ہے۔ LWW کو وقت کی ہم آہنگی کی ضرورت ہے — ٹائم اسٹیمپ سرور پر بنایا جانا چاہیے یا منطقی گھڑی (لیمپورٹ گھڑیاں) استعمال کرنی چاہیے۔ نقصان: ایک صارف کا ڈیٹا بغیر اطلاع کے دوسرے صارف کے ڈیٹا سے اوور رائٹ ہو سکتا ہے۔

OT (آپریشنل ٹرانسفارمیشن) — الگورتھم جو Google Docs اور Figma ریئل ٹائم باہمی ترمیم کے لیے استعمال کرتے ہیں، بشمول آف لائن موڈ۔ OT آپریشنز کو تبدیل کرتا ہے تاکہ وہ دستاویز کی کسی بھی حالت پر لاگو ہو سکیں، بغیر لاک کے مستقل مزاجی کو یقینی بناتا ہے۔ CRDT (کنفلیکٹ فری ریپلیکیٹڈ ڈیٹا ٹائپس) — OT کا متبادل جو موبائل ایپس میں مقبولیت حاصل کر رہا ہے: ڈیٹا اس طرح تشکیل دیا جاتا ہے کہ تصادم مرکزی سرور کے بغیر ریاضیاتی طور پر حل ہو سکیں۔

کسٹم انضمام — سادہ ڈیٹا ماڈل (نوٹس، رابطے) والی ایپس کے لیے کسٹم انضمام کے قواعد لاگو کیے جا سکتے ہیں۔ مثال کے طور پر، نوٹ کے لیے: اگر متن دو ورژنز میں تبدیل کیا گیا ہے تو انہیں الگ کرنے والے کے ساتھ جوڑ کر ضم کریں۔ صارف کے ذریعے حل کردہ تصادم — اگر خودکار انضمام ممکن نہ ہو تو صارف کو دونوں ورژن دکھائیں اور انتخاب کرنے دیں۔ Dropbox (2024) آف لائن فائل تصادم کے لیے اس طریقہ کار کو استعمال کرتا ہے، «Conflicted Copy» کے سابقہ کے ساتھ کاپیاں بناتا ہے۔

Idempotency keys — نقل سے تحفظ

Idempotency Key — ایک منفرد آپریشن شناخت کنندہ جو سرور نقل درخواستوں کا پتہ لگانے کے لیے استعمال کرتا ہے۔ اگر کلائنٹ اسی کلید کے ساتھ وہی درخواست بھیجتا ہے تو سرور دوبارہ عمل کیے بغیر پہلے سے مکمل شدہ آپریشن کا نتیجہ لوٹاتا ہے۔ یہ Offline Queue کے لیے انتہائی اہم ہے، جہاں نیٹ ورک کی غلطیوں کی وجہ سے دوبارہ بھیجنا ممکن ہے۔

Idempotency key کی شکل UUID یا درخواست کے پیرامیٹرز کا ہیش ہے۔ سرور کو نقل کا پتہ لگانے کے لیے کچھ وقت (عام طور پر 24 گھنٹے) کے لیے نتیجہ کے ساتھ مکمل شدہ کلیدوں کو ذخیرہ کرنا چاہیے۔ Stripe API (2024) حوالہ مثال ہے: کلید Idempotency-Key ہیڈر میں بھیجی جاتی ہے، اور اسی کلید کے ساتھ دہرائی گئی درخواستیں کیشڈ جواب لوٹاتی ہیں۔

کلائنٹ سائیڈ جنریشن — کلید آپریشن بھیجنے سے پہلے کلائنٹ پر بنائی جاتی ہے اور QueuedOperation ٹیبل میں محفوظ کی جاتی ہے۔ دوبارہ کوشش کرنے پر کلید تبدیل نہیں ہوتی۔ Exactly-once آرکیٹیکچر — کلائنٹ پر idempotency key اور سرور پر ڈیڈپلیکیشن کا امتزاج اس بات کی ضمانت دینے کا واحد طریقہ ہے کہ آپریشن دو بار نہیں ہوگا۔

fun createOperation(type: OperationType, payload: String): QueuedOperation =
    QueuedOperation(
        id = UUID.randomUUID().toString(),
        type = type,
        endpoint = type.endpoint,
        payload = payload,
        timestamp = currentTimeMillis(),
        idempotencyKey = UUID.randomUUID().toString()
    )

ہر آپریشن دو UUID حاصل کرتا ہے: ایک — قطار میں ریکارڈ کا شناخت کنندہ، دوسرا — سرور کے لیے idempotency key۔ idempotencyKey کے ذریعے سرور سائیڈ ڈیڈپلیکیشن اس بات کی ضمانت دیتی ہے کہ دوبارہ بھیجنے پر بھی آرڈر نقل نہیں ہوگا۔