किसी भी ऐप को मानें: हर डिवाइस एक लोकल है। स्टडी ऐक्शन एक के साथ-साथ एक append-only (outbox) में लिखे जाते हैं; दोबारा कनेक्ट होने पर डिवाइस अपने और पिछले सिंक के बाद के । कॉन्फ्लिक्ट किसी एक ग्लोबल नियम से , बल्कि के आधार पर सुलझाए जाते हैं।
किसी भी ऐप को मानें: हर डिवाइस एक लोकल है। स्टडी ऐक्शन एक के साथ-साथ एक append-only (outbox) में लिखे जाते हैं; दोबारा कनेक्ट होने पर डिवाइस अपने और पिछले सिंक के बाद के । कॉन्फ्लिक्ट किसी एक ग्लोबल नियम से , बल्कि के आधार पर सुलझाए जाते हैं।
मानसिक मॉडल: इसे git की तरह समझें — हर डिवाइस ऑफ़लाइन रहते हुए लोकल रूप से "commit" करता है, और सिंक एक merge है, overwrite नहीं।
Device (offline) Server = source of truth
┌──────────────────┐ on reconnect ┌───────────────────────────┐
│ Local DB (SQLite)│ push ops (delta) │ Sync API /sync │
│ + Op log (outbox)│ ─────────────────▶ │ • idempotent by op.id │
│ cursor = lastSeen│ ◀───────────────── │ • merge by semantics │
└──────────────────┘ pull changes>cursor└───────────────────────────┘
Progress DB (Postgres)
फ़ोन की clock अविश्वसनीय होती हैं और दो डिवाइस एक ही record को ऑफ़लाइन एडिट कर सकते हैं, इसलिए "last write wins" (LWW) चुपचाप डेटा खो देता है। semantics के आधार पर resolve करें:
// op के पास id है -> idempotently लागू करें (retries दोबारा count नहीं करते)। clientTs पर भरोसा नहीं किया जाता।
function mergeProgress(server, op) {
return {
// progress सिर्फ़ बढ़ता है -> max: कोई देर से आया पुराना op इसे पीछे नहीं खींचता
progress: Math.max(server.progress ?? 0, op.progress),
// studiedMs एक additive counter है -> delta जोड़ें, overwrite न करें
studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
};
}
यहाँ, सादा LWW एक stale डिवाइस को, जो देर से progress: 0.3 के साथ सिंक करता है, server के 0.9 को overwrite करने देगा → progress खो जाएगा। max लेना और studiedMs को जोड़ना सिंक को order-independent बनाता है — तब सुरक्षित जब लाखों डिवाइस skewed clocks के साथ सिंक करते हैं।
इंटरव्यूअर यह परख रहा है कि क्या आप जानते हैं कि client clocks पर भरोसा नहीं किया जा सकता (इसलिए शुद्ध timestamp LWW नहीं), क्या आप सिंक को idempotent बनाते हैं (op ids), और क्या आप डेटा के अर्थ के आधार पर merge करते हैं। एक कमज़ोर जवाब: "timestamps इस्तेमाल करो, last write wins।" एक मज़बूत जवाब: replica + op log + idempotency + per-field merge + server as source of truth — और LWW की data-loss विफलता को स्पष्ट रूप से नाम देना।
LWW सस्ता है पर lossy; semantic merge को per-field सोच चाहिए पर कुछ नहीं खोता। पूर्ण CRDT/OT की ओर तभी बढ़ें जब आपको सच में collaborative editing चाहिए (notes, documents) — यह महँगा है, इसलिए इसे हर जगह इस्तेमाल न करें।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें