Offline Queue: सिद्धांत, रणनीतियाँ और कार्य तंत्र

ऑफलाइन कतार क्या है?

Offline Queue संचालन (बनाना, अद्यतन करना, हटाना) का एक क्रमबद्ध संग्रह है जिसे एप्लिकेशन स्थानीय रूप से सहेजता है जब डिवाइस के पास नेटवर्क तक पहुंच नहीं होती है। कनेक्शन बहाल होने पर, कतार उसी क्रम में सर्वर पर संचालन भेजती है जिसमें उपयोगकर्ता ने उन्हें किया था।

एक परिदृश्य की कल्पना करें: एक मैसेंजर उपयोगकर्ता बिना इंटरनेट के मेट्रो में संदेश टाइप करता है। «भेजें» का प्रत्येक टैप Offline Queue में जुड़ जाता है। जब ट्रेन सुरंग से बाहर निकलती है और नेटवर्क उपलब्ध होता है, सभी संदेश स्वचालित रूप से भेज दिए जाते हैं। उपयोगकर्ता अनुभव — सहज: उन्हें पता नहीं चलता कि वे ऑफलाइन थे, सिवाय भेजने में थोड़ी देरी के।

Uber Engineering (2024) के अनुसार, उनकी ऑफलाइन कतार खराब कनेक्टिविटी वाले क्षेत्रों में प्रतिदिन 2 मिलियन से अधिक संचालन संसाधित करती है। कतार 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) और निष्पादक (executor)। भंडारण — 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 द्वारा सर्वर-साइड डिडुप्लीकेशन गारंटी देता है कि पुनर्प्रेषण पर भी, आदेश दोहराया नहीं जाएगा।