Progetta la sincronizzazione offline per un'app di apprendimento: come risolvi i conflitti?

Question

IT Interview Practice · Accepted Answer

Tratta l'app come **offline-first**: ogni dispositivo è una **replica** locale. Le azioni di studio vengono scritte in un **DB locale** più un **op log** append-only (outbox); alla riconnessione il dispositivo **invia le sue ops** e **scarica le modifiche del server** dall'ultima sincronizzazione. I conflitti si risolvono **non** con un'unica regola globale ma con la **semantica di ogni campo dati**.

**Modello mentale:** pensalo come **git** — ogni dispositivo "committa" localmente mentre è offline, e la sync è un **merge**, non una sovrascrittura.

## Architettura

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

- **DB locale + op log:** ogni modifica è un'**op immutabile con id generato dal client** + versione, accodata mentre è offline. La UI legge/scrive localmente, così resta fluida senza rete.
- **Servizio di sync:** sync **cursor-based delta** — invia le ops dal cursor del client, scarica le modifiche più recenti. Ogni sync sposta solo il **delta**, non l'intero dataset → 5M utenti restano economici.
- **Risolutore di conflitti:** unisce in base al significato per campo (sotto). **Il server è la source of truth**; il client risolve prima per fluidità, poi il server riapplica lo **stesso** merge deterministico.

## Risoluzione dei conflitti (il cuore)

Gli orologi dei telefoni sono **inaffidabili** e due dispositivi possono modificare lo stesso record offline, quindi **il "last write wins" (LWW) perde dati silenziosamente**. Risolvi per semantica:

- **Campi monotonici** (avanzamento lezione) → prendi il **max**.
- **Contatori additivi** (tempo totale di studio) → **somma il delta** (contatore grow-only in stile CRDT).
- **Vero "stato più recente"** (posizione di scroll) → il LWW è accettabile.

```js
// op ha un id -> applica in modo idempotente (i retry non contano due volte). clientTs NON è affidabile.
function mergeProgress(server, op) {
  return {
    // progress aumenta soltanto -> max: un vecchio op in ritardo non lo riporta mai indietro
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs è un contatore additivo -> aggiungi il delta, non sovrascrivere
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Qui il LWW puro lascerebbe un dispositivo obsoleto che sincronizza in ritardo con `progress: 0.3` **sovrascrivere** lo `0.9` del server → avanzamento perso. Prendere il `max` e sommare `studiedMs` rende la sync **indipendente dall'ordine** — sicura quando milioni di dispositivi sincronizzano con orologi sfasati.

## Ottica del colloquio

L'intervistatore verifica se sai che **gli orologi client non sono affidabili** (quindi non timestamp LWW puro), se rendi la **sync idempotente** (op id) e se **unisci in base al significato dei dati**. Risposta **debole**: "usa i timestamp, last write wins." Risposta **forte**: replica + op log + idempotenza + merge per campo + server come source of truth — e nominare esplicitamente il fallimento di **perdita dati** del LWW.

## Compromessi

Il LWW è economico ma con perdite; il merge semantico richiede ragionamento per campo ma **non perde nulla**. Ricorri a **CRDT/OT** completi solo quando serve vera editing collaborativo (note, documenti) — è costoso, quindi non usarlo per tutto.

Architettura

Risoluzione dei conflitti (il cuore)

Ottica del colloquio

Compromessi

Domande correlate