Buni ulandanishaji wa nje ya mtandao (offline sync) kwa programu ya kujifunza: unatatuaje migongano?

Question

IT Interview Practice · Accepted Answer

Chukulia programu kama **offline-first**: kila kifaa ni **replica** ya ndani. Vitendo vya kujifunza vinaandikwa kwenye **local DB** pamoja na **op log** ya kuongeza-tu (outbox); kifaa kinapoungana tena kinasukuma **ops zake** na **kuvuta mabadiliko ya server** tangu ulandanishaji wake wa mwisho. Migongano hutatuliwa **si** kwa sheria moja ya kidunia bali kwa **semantiki ya kila uga wa data**.

**Mfano wa kufikiri:** ifikirie kama **git** — kila kifaa "kina-commit" ndani wakati kikiwa nje ya mtandao, na ulandanishaji ni **merge**, si kufuta na kuandika juu.

## Muundo

```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:** kila badiliko ni **op isiyobadilika yenye id iliyozalishwa na client** + version, iliyowekwa kwenye foleni wakati wa kuwa nje ya mtandao. UI inasoma/inaandika ndani ili ibaki laini bila mtandao.
- **Huduma ya sync:** ulandanishaji wa **delta unaotegemea cursor** — sukuma ops tangu cursor ya client, vuta mabadiliko mapya kuliko hiyo. Kila ulandanishaji unasogeza **delta** tu, si dataset nzima → watumiaji milioni 5 wanabaki nafuu.
- **Kitatua migongano:** unamerge kwa maana ya kila uga (hapa chini). **Server ni source of truth**; client hutatua kwanza kwa ulaini, kisha server huweka tena **merge** ile ile ya kutabirika.

## Utatuzi wa migongano (kiini)

Saa za simu **haziaminiki** na vifaa viwili vinaweza kuhariri rekodi ile ile nje ya mtandao, kwa hivyo **"last write wins" (LWW) hupoteza data kimya kimya**. Tatua kwa semantiki:

- **Uga za monotonic** (maendeleo ya somo) → chukua **max**.
- **Counters za kuongeza** (jumla ya muda wa kusoma) → **ongeza delta** (grow-only counter ya mtindo wa CRDT).
- **"Hali ya hivi punde" halisi** (nafasi ya scroll) → LWW inakubalika.

```js
// op ina id -> tumia kwa idempotency (retries hazihesabu mara mbili). clientTs HAIAMINIWI.
function mergeProgress(server, op) {
  return {
    // progress inaongezeka tu -> max: op ya zamani iliyochelewa haitairudisha nyuma
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs ni counter ya kuongeza -> ongeza delta, usifute na kuandika juu
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Hapa, LWW ya kawaida ingeruhusu kifaa cha zamani kinacholandanisha kuchelewa chenye `progress: 0.3` **kufuta na kuandika juu** ya `0.9` ya server → maendeleo yaliyopotea. Kuchukua `max` na kujumlisha `studiedMs` hufanya ulandanishaji **usitegemee mpangilio** — salama wakati vifaa milioni vinalandanisha vikiwa na saa zilizopotoka.

## Mtazamo wa mahojiano

Mhojaji anachunguza kama unajua **saa za client haziwezi kuaminiwa** (kwa hivyo si LWW ya timestamp tupu), kama unafanya **sync kuwa idempotent** (op ids), na kama **unamerge kwa maana ya data**. Jibu **dhaifu**: "tumia timestamps, last write wins." Jibu **imara**: replica + op log + idempotency + merge kwa kila uga + server kama source of truth — na kutaja waziwazi kutofaulu kwa LWW kwa **kupoteza data**.

## Ubadilishano (trade-offs)

LWW ni nafuu lakini yenye upotevu; semantic merge inahitaji kufikiri kwa kila uga lakini **haipotezi chochote**. Fikia **CRDT/OT** kamili tu unapohitaji uhariri wa ushirikiano wa kweli (notes, documents) — ni ghali, kwa hivyo usiitumie kwa kila kitu.

Muundo

Utatuzi wa migongano (kiini)

Mtazamo wa mahojiano

Ubadilishano (trade-offs)

Maswali yanayohusiana