Concevez la synchronisation hors ligne d'une application d'apprentissage : comment résolvez-vous les conflits ?

Question

IT Interview Practice · Accepted Answer

Considérez l'application comme **offline-first** : chaque appareil est une **réplique** locale. Les actions d'étude sont écrites dans une **base de données locale** ainsi que dans un **op log** en append-only (outbox) ; à la reconnexion, l'appareil **pousse ses ops** et **récupère les changements du serveur** depuis sa dernière synchronisation. Les conflits sont résolus **non** par une règle globale unique mais par la **sémantique de chaque champ de données**.

**Modèle mental :** imaginez cela comme **git** — chaque appareil « commit » localement en mode hors ligne, et la synchronisation est un **merge**, pas un écrasement.

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

- **Base de données locale + op log :** chaque changement est un **op immuable avec un id généré côté client** + version, mis en file d'attente en mode hors ligne. L'UI lit/écrit localement pour rester fluide sans réseau.
- **Service de sync :** synchronisation **delta basée sur un curseur** — pousser les ops depuis le curseur du client, récupérer les changements plus récents. Chaque sync ne transfère que le **delta**, pas l'ensemble du dataset → 5M d'utilisateurs reste peu coûteux.
- **Résolveur de conflits :** fusionne selon la signification de chaque champ (ci-dessous). Le **serveur est la source de vérité** ; le client résout d'abord pour la fluidité, puis le serveur ré-applique le **même** merge déterministe.

## Résolution des conflits (le cœur)

Les horloges des téléphones sont **peu fiables** et deux appareils peuvent modifier le même enregistrement hors ligne, donc **le « last write wins » (LWW) perd des données silencieusement**. Résolvez par la sémantique :

- **Champs monotones** (progression d'une leçon) → prendre le **max**.
- **Compteurs additifs** (temps d'étude total) → **ajouter le delta** (compteur grow-only de style CRDT).
- **Véritable « dernier état »** (position de défilement) → LWW est acceptable.

```js
// op possède un id -> appliquer de façon idempotente (les retries ne comptent pas double). clientTs n'est PAS de confiance.
function mergeProgress(server, op) {
  return {
    // progress ne fait qu'augmenter -> max : un vieil op arrivé en retard ne le fait jamais reculer
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs est un compteur additif -> ajouter le delta, ne pas écraser
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Ici, un simple LWW laisserait un appareil obsolète se synchronisant en retard avec `progress: 0.3` **écraser** le `0.9` du serveur → progression perdue. Prendre le `max` et sommer `studiedMs` rend la synchronisation **indépendante de l'ordre** — sûr quand des millions d'appareils se synchronisent avec des horloges décalées.

## L'angle de l'entretien

L'examinateur cherche à savoir si vous savez que **les horloges clientes ne sont pas de confiance** (donc pas de LWW pur par timestamp), si vous rendez la **synchronisation idempotente** (ids d'op), et si vous **fusionnez selon la signification des données**. Une **mauvaise** réponse : « utiliser des timestamps, last write wins ». Une **bonne** réponse : réplique + op log + idempotence + merge par champ + serveur comme source de vérité — et nommer explicitement la **perte de données** du LWW.

## Compromis

Le LWW est peu coûteux mais avec perte ; le merge sémantique demande une réflexion par champ mais **ne perd rien**. Ne recourez à un **CRDT/OT** complet que lorsque vous avez besoin d'une véritable édition collaborative (notes, documents) — c'est coûteux, donc ne l'utilisez pas partout.

Architecture

Résolution des conflits (le cœur)

L'angle de l'entretien

Compromis

Questions connexes