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 रियल-टाइम सिंक के लिए WebSocket का उपयोग करता है जिसमें HTTP polling पर स्वचालित फ़ॉलबैक है।

हायब्रिड दृष्टिकोण — प्रकारों का एक संयोजन: ऐप स्टार्टअप पर बेसलाइन डेटा के लिए पूर्ण सिंक, फिर अपडेट के लिए इन्क्रिमेंटल सिंक, और महत्वपूर्ण घटनाओं के लिए FCM के जरिए पुश सिंक। यह गति और संसाधन बचत दोनों प्रदान करता है।

इन्क्रिमेंटल सिंक — चेकपॉइंट और डेल्टा कैसे काम करते हैं

चेकपॉइंट (Checkpoint) — एक मान जिसे क्लाइंट सिंक सत्रों के बीच संग्रहीत करता है। आमतौर पर यह अंतिम सफलतापूर्वक सिंक किए गए रिकॉर्ड का updated_at होता है। अगले सिंक पर, क्लाइंट चेकपॉइंट सर्वर को भेजता है, और सर्वर चेकपॉइंट के बाद updated_at वाले सभी रिकॉर्ड लौटाता है। कर्सर-बेसड पैजिनेशन — एक उन्नत संस्करण जहां सर्वर डेटा के साथ एक कर्सर (अगले पेज का संकेतक) लौटाता है।

डेल्टा सिंक (Delta sync) — सर्वर डेटा की वर्तमान स्थिति और क्लाइंट द्वारा आखिरी बार देखे गए स्नैपशॉट के बीच का अंतर निकालता है। सभी रिकॉर्ड भेजने के बजाय, केवल ऑपरेशन (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» देखें)। क्यू एक विश्वसनीय Sync Engine की नींव है: इसके बिना, सिंक्रोनाइजेशन परिवर्तन डेलीवरी की गारंटी नहीं देता।

चरण 4: कंफ़्लिक्ट रिजॉल्वर चुनें — साधारण मामलों के लिए LWW, सहयोगात्मक संपादन के लिए CRDT, व्यवसायिक तर्क के लिए कस्टम मर्ज। नियम: रिजॉल्वर आइडेंपोटेंट होना चाहिए — एही ऑपरेशन को दोबारा लागू करने से वही परिणाम मिलना चाहिए।

चरण 5: निगरानी और मैट्रिक्स — प्रत्येक सिंक को लॉग करें: रिकॉर्ड गिनती, निष्पादन समय, कंफ़्लिक्ट गिनती, त्रुटियाँ। Firebase Crashlytics या Sentry (2025) रियल-टाइम में सिंक त्रुटियों को ट्रैक करने की अनुमति देते हैं।

Realm Team (2024) के अनुसार, एक सामान्य मोबाइल ऐप Sync Engine प्रति दिन प्रति डिवाइस 100–500 सिंक्रोनाइजेशन का प्रसंस्करण करता है, जो प्रति सत्र औसतन 50–200 KB डेटा स्थानांतरित करता है। प्रोटोकॉल ऑप्टिमाइजेशन — JSON के बजाय Protobuf संपीडन का उपयोग — डेटा स्थानांतरण मात्रा को 40–60% तक और कम करता है।