Zaprojektuj synchronizację offline dla aplikacji edukacyjnej: jak rozwiązujesz konflikty?

Question

IT Interview Practice · Accepted Answer

Traktuj aplikację jako **offline-first**: każde urządzenie to lokalna **replica**. Akcje nauki są zapisywane do **lokalnej bazy** plus do dopisywanego tylko na końcu **op log** (outbox); po ponownym połączeniu urządzenie **wypycha swoje ops** i **pobiera zmiany z serwera** od ostatniej synchronizacji. Konflikty rozwiązuje się **nie** jedną globalną regułą, lecz **semantyką każdego pola danych**.

**Model mentalny:** pomyśl o tym jak o **gicie** — każde urządzenie „commituje” lokalnie w trybie offline, a synchronizacja to **merge**, a nie nadpisanie.

## Architektura

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

- **Lokalna baza + op log:** każda zmiana to **niezmienny op z id generowanym po stronie klienta** + wersja, kolejkowany w trybie offline. UI czyta/zapisuje lokalnie, więc pozostaje płynny bez sieci.
- **Usługa synchronizacji:** synchronizacja **delta oparta na cursorze** — wypchnij ops od cursora klienta, pobierz zmiany nowsze niż on. Każda synchronizacja przenosi tylko **deltę**, a nie cały zbiór danych → 5 mln użytkowników pozostaje tanie.
- **Resolver konfliktów:** merguje według znaczenia każdego pola (poniżej). **Serwer jest source of truth**; klient rozwiązuje najpierw dla płynności, a następnie serwer ponownie stosuje **ten sam** deterministyczny merge.

## Rozwiązywanie konfliktów (sedno)

Zegary telefonów są **niewiarygodne**, a dwa urządzenia mogą edytować ten sam rekord offline, więc **„last write wins” (LWW) po cichu gubi dane**. Rozwiązuj według semantyki:

- **Pola monotoniczne** (postęp lekcji) → weź **max**.
- **Liczniki addytywne** (całkowity czas nauki) → **dodaj deltę** (grow-only counter w stylu CRDT).
- **Prawdziwy „najnowszy stan”** (pozycja przewijania) → LWW jest do zaakceptowania.

```js
// op ma id -> stosuj idempotentnie (ponowienia nie liczą podwójnie). clientTs NIE jest ufany.
function mergeProgress(server, op) {
  return {
    // postęp tylko rośnie -> max: spóźniony stary op nigdy nie cofa go wstecz
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs to licznik addytywny -> dodaj deltę, nie nadpisuj
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Tutaj zwykłe LWW pozwoliłoby, aby przeterminowane urządzenie synchronizujące się z opóźnieniem z `progress: 0.3` **nadpisało** serwerowe `0.9` → utracony postęp. Wzięcie `max` i sumowanie `studiedMs` czyni synchronizację **niezależną od kolejności** — bezpieczną, gdy miliony urządzeń synchronizują się z rozbieżnymi zegarami.

## Perspektywa rozmowy

Prowadzący sprawdza, czy wiesz, że **zegarom klienta nie można ufać** (więc nie czyste timestamp LWW), czy czynisz **synchronizację idempotentną** (op id), oraz czy **mergujesz według znaczenia danych**. **Słaba** odpowiedź: „użyj timestampów, last write wins”. **Mocna** odpowiedź: replica + op log + idempotencja + merge per-pole + serwer jako source of truth — i wyraźne nazwanie awarii **utraty danych** w LWW.

## Kompromisy

LWW jest tanie, ale stratne; semantyczny merge wymaga przemyślenia każdego pola, ale **niczego nie gubi**. Sięgaj po pełne **CRDT/OT** tylko wtedy, gdy potrzebujesz prawdziwej edycji współdzielonej (notatki, dokumenty) — jest kosztowne, więc nie używaj go do wszystkiego.

Architektura

Rozwiązywanie konfliktów (sedno)

Perspektywa rozmowy

Kompromisy

Powiązane pytania