लर्निंग अ‍ॅपसाठी offline sync डिझाइन करा: conflicts कसे resolve कराल?

Question

IT Interview Practice · Accepted Answer

अ‍ॅपला **offline-first** समजा: प्रत्येक device हे एक local **replica** आहे. अभ्यासाच्या क्रिया एका **local DB** मध्ये आणि append-only **op log** (outbox) मध्ये लिहिल्या जातात; पुन्हा connect झाल्यावर device त्याच्या **ops push करते** आणि शेवटच्या sync नंतरचे **server changes pull करते**. Conflicts एका global rule ने **नाही** तर प्रत्येक data field च्या **semantics** नुसार resolve केले जातात.

**Mental model:** याला **git** सारखे समजा — प्रत्येक device offline असताना locally "commits" करते, आणि sync म्हणजे एक **merge** आहे, overwrite नाही.

## Architecture

```text
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)
```

- **Local DB + op log:** प्रत्येक change हा **client-generated id असलेला immutable op** + version असतो, जो offline असताना queue केला जातो. UI locally read/write करते त्यामुळे network शिवायही ते smooth राहते.
- **Sync service:** **cursor-based delta** sync — client cursor नंतरचे ops push करा, त्याहून नवीन changes pull करा. प्रत्येक sync फक्त **delta** हलवते, संपूर्ण dataset नाही → 5M users स्वस्तात राहतात.
- **Conflict resolver:** प्रत्येक field च्या अर्थानुसार merge करते (खाली). **Server हा source of truth आहे**; smoothness साठी client आधी resolve करते, नंतर server **तोच** deterministic merge पुन्हा apply करते.

## Conflict resolution (गाभा)

फोनची clocks **unreliable** असतात आणि दोन devices एकाच record ला offline edit करू शकतात, त्यामुळे **"last write wins" (LWW) गुपचूप data गमावते**. Semantics नुसार resolve करा:

- **Monotonic fields** (lesson progress) → **max** घ्या.
- **Additive counters** (total study time) → **delta add करा** (CRDT-style grow-only counter).
- **खरे "latest state"** (scroll position) → LWW स्वीकार्य आहे.

```js
// op has an id -> apply idempotently (retries don't double-count). clientTs is NOT trusted.
function mergeProgress(server, op) {
  return {
    // progress only increases -> max: a late old op never drags it backward
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs is an additive counter -> add the delta, don't overwrite
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

इथे, plain LWW मुळे उशिरा sync होणारे stale device `progress: 0.3` घेऊन server च्या `0.9` ला **overwrite** करेल → progress गमावले. `max` घेणे आणि `studiedMs` ची बेरीज करणे sync ला **order-independent** बनवते — जेव्हा लाखो devices skewed clocks सह sync करतात तेव्हा सुरक्षित.

## Interview lens

Interviewer हे तपासत असतो की तुम्हाला माहीत आहे का की **client clocks वर विश्वास ठेवता येत नाही** (म्हणजे शुद्ध 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 चे स्पष्ट नाव घेणे.

## Trade-offs

LWW स्वस्त पण lossy आहे; semantic merge ला per-field विचार लागतो पण **काहीच गमावत नाही**. खऱ्या collaborative editing साठीच (notes, documents) पूर्ण **CRDT/OT** कडे वळा — ते महाग आहे, म्हणून प्रत्येक गोष्टीसाठी वापरू नका.

Architecture

Conflict resolution (गाभा)

Interview lens

Trade-offs

संबंधित प्रश्न