ఒక learning app కోసం offline sync డిజైన్ చేయండి: conflicts ను ఎలా resolve చేస్తారు?

Question

IT Interview Practice · Accepted Answer

App ను **offline-first** గా భావించండి: ప్రతి device ఒక local **replica**. Study actions ను ఒక **local DB** లో మరియు append-only **op log** (outbox) లో వ్రాస్తారు; reconnect అయినప్పుడు device తన **ops ను push చేస్తుంది** మరియు చివరి sync నుండి **server changes ను pull చేస్తుంది**. Conflicts ను ఒక global rule తో **కాదు**, ప్రతి data field యొక్క **semantics ను బట్టి** resolve చేస్తారు.

**Mental model:** దీన్ని **git** లా భావించండి — ప్రతి device offline లో ఉన్నప్పుడు locally "commit" చేస్తుంది, మరియు sync అనేది overwrite కాదు, ఒక **merge**.

## 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 చేయండి, దాని కంటే newer changes ను pull చేయండి. ప్రతి sync పూర్తి dataset ను కాదు, కేవలం **delta** ను మాత్రమే move చేస్తుంది → 5M users cheap గా ఉంటుంది.
- **Conflict resolver:** per-field meaning ను బట్టి merge చేస్తుంది (కింద). **Server అనేది source of truth**; smoothness కోసం client మొదట resolve చేస్తుంది, తర్వాత server అదే deterministic merge ను తిరిగి apply చేస్తుంది.

## Conflict resolution (core భాగం)

Phone 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 acceptable.

```js
// op కి ఒక id ఉంది -> idempotently apply చేయండి (retries double-count చేయవు). clientTs ను నమ్మరు.
function mergeProgress(server, op) {
  return {
    // progress కేవలం పెరుగుతుంది -> max: late old op దాన్ని ఎప్పటికీ వెనక్కి లాగదు
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs ఒక additive counter -> delta ను add చేయండి, overwrite చేయకండి
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

ఇక్కడ, plain LWW అయితే late గా sync అయ్యే ఒక stale device `progress: 0.3` తో server యొక్క `0.9` ను **overwrite** చేసేది → progress కోల్పోవడం. `max` తీసుకోవడం మరియు `studiedMs` ను sum చేయడం sync ను **order-independent** గా చేస్తుంది — skewed clocks తో millions of devices sync అయినప్పుడు safe.

## Interview lens

**Client clocks ను నమ్మలేమని** మీకు తెలుసా (కాబట్టి pure timestamp LWW కాదు), మీరు **sync ను idempotent** గా చేస్తారా (op ids), మరియు **data meaning ను బట్టి merge** చేస్తారా అని interviewer probe చేస్తున్నారు. ఒక **weak** answer: "timestamps వాడండి, last write wins." ఒక **strong** answer: replica + op log + idempotency + per-field merge + server as source of truth — మరియు LWW యొక్క **data-loss** failure ను స్పష్టంగా పేర్కొనడం.

## Trade-offs

LWW cheap కానీ lossy; semantic merge కి per-field ఆలోచన అవసరం కానీ **ఏమీ కోల్పోదు**. నిజమైన collaborative editing (notes, documents) అవసరమైనప్పుడు మాత్రమే పూర్తి **CRDT/OT** వైపు వెళ్ళండి — అది costly, కాబట్టి ప్రతిదానికీ దాన్ని వాడకండి.

Architecture

Conflict resolution (core భాగం)

Interview lens

Trade-offs

సంబంధిత ప్రశ్నలు