લર્નિંગ એપ માટે offline sync ડિઝાઇન કરો: તમે conflicts કેવી રીતે ઉકેલો છો?

Question

IT Interview Practice · Accepted Answer

એપને **offline-first** તરીકે ગણો: દરેક device એ એક લોકલ **replica** છે. અભ્યાસની ક્રિયાઓ એક **local DB** ઉપરાંત append-only **op log** (outbox) માં લખાય છે; reconnect થાય ત્યારે device **પોતાના ops push કરે છે** અને છેલ્લા sync પછીના **server changes pull કરે છે**. Conflicts કોઈ એક global નિયમથી **નહીં** પણ **દરેક data field ના semantics** થી ઉકેલાય છે.

**Mental model:** તેને **git** જેવું સમજો — દરેક device offline હોય ત્યારે લોકલી "commit" કરે છે, અને 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 લોકલી read/write કરે છે તેથી network વગર પણ તે smooth રહે છે.
- **Sync service:** **cursor-based delta** sync — client cursor પછીના ops push કરો, તેનાથી નવા changes pull કરો. દરેક sync ફક્ત **delta** ખસેડે છે, આખો dataset નહીં → 5M users સસ્તું રહે છે.
- **Conflict resolver:** per-field meaning પ્રમાણે merge કરે છે (નીચે). **Server એ source of truth છે**; client smoothness માટે પહેલા resolve કરે છે, પછી server **એ જ** deterministic merge ફરીથી apply કરે છે.

## Conflict resolution (the core)

ફોનની clocks **અવિશ્વસનીય** હોય છે અને બે devices એક જ record ને offline એડિટ કરી શકે છે, તેથી **"last write wins" (LWW) ચૂપચાપ data ગુમાવે છે**. Semantics પ્રમાણે ઉકેલો:

- **Monotonic fields** (lesson progress) → **max** લો.
- **Additive counters** (total study time) → **delta ઉમેરો** (CRDT-style grow-only counter).
- **સાચી "latest state"** (scroll position) → LWW સ્વીકાર્ય છે.

```js
// 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 એક stale device ને મોડું sync થતાં `progress: 0.3` સાથે server ના `0.9` ને **overwrite** કરવા દેશે → ગુમાવેલો progress. `max` લેવું અને `studiedMs` નો સરવાળો કરવો sync ને **order-independent** બનાવે છે — જ્યારે લાખો devices skewed clocks સાથે sync કરે ત્યારે સલામત.

## Interview lens

Interviewer તપાસી રહ્યો છે કે તમે જાણો છો કે **client clocks પર ભરોસો ન કરાય** (એટલે pure timestamp LWW નહીં), તમે **sync ને idempotent** બનાવો છો (op ids), અને તમે **data meaning પ્રમાણે 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 વિચાર જોઈએ પણ તે **કંઈ ગુમાવતું નથી**. પૂર્ણ **CRDT/OT** ત્યારે જ પકડો જ્યારે તમને સાચી collaborative editing જોઈએ (notes, documents) — તે ખર્ચાળ છે, તેથી દરેક વસ્તુ માટે તેનો ઉપયોગ ન કરો.

Architecture

Conflict resolution (the core)

Interview lens

Trade-offs

સંબંધિત પ્રશ્નો