एपलाई को रूपमा हेर्नुहोस्: प्रत्येक device एउटा local हो। अध्ययनका actions local मा र append-only (outbox) मा लेखिन्छन्; reconnect हुँदा device ले र अन्तिम sync पछिका । Conflicts कुनै एउटै global नियमले बरु ले resolve गरिन्छ।
एपलाई को रूपमा हेर्नुहोस्: प्रत्येक device एउटा local हो। अध्ययनका actions local मा र append-only (outbox) मा लेखिन्छन्; reconnect हुँदा device ले र अन्तिम sync पछिका । Conflicts कुनै एउटै global नियमले बरु ले resolve गरिन्छ।
Mental model: यसलाई git जस्तै सोच्नुहोस् — प्रत्येक device offline हुँदा locally "commit" गर्छ, र sync एउटा 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)
फोनका clocks अविश्वसनीय हुन्छन् र दुई devices ले offline हुँदा उही record edit गर्न सक्छन्, त्यसैले "last write wins" (LWW) ले चुपचाप data गुमाउँछ। semantics अनुसार resolve गर्नुहोस्:
// op मा एउटा id छ -> idempotently apply गर्नुहोस् (retries ले double-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 ले ढिलो sync हुने बासी device लाई progress: 0.3 सँग server को 0.9 लाई overwrite गर्न दिन्छ → progress गुम्यो। max लिनु र studiedMs जोड्नुले sync लाई order-independent बनाउँछ — जब लाखौं devices skewed clocks सँग sync गर्छन् तब सुरक्षित।
Interviewer ले जाँच्दैछ कि तपाईंलाई थाहा छ कि client clocks मा भरोसा गर्न सकिँदैन (त्यसैले pure timestamp LWW होइन), तपाईं sync लाई idempotent बनाउनुहुन्छ कि (op ids), र तपाईं data अर्थ अनुसार merge गर्नुहुन्छ कि। एउटा कमजोर उत्तर: "timestamps प्रयोग गर, last write wins।" एउटा बलियो उत्तर: replica + op log + idempotency + per-field merge + server as source of truth — र LWW को data-loss failure स्पष्ट रूपमा नाम लिएर।
LWW सस्तो तर lossy छ; semantic merge लाई per-field सोच चाहिन्छ तर यसले केही गुमाउँदैन। साँचो collaborative editing (notes, documents) चाहिँदा मात्र पूर्ण CRDT/OT तिर जानुहोस् — यो महँगो छ, त्यसैले सबैका लागि यो प्रयोग नगर्नुहोस्।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्