Спроектируйте офлайн-синхронизацию для обучающего приложения: как разрешать конфликты?

Question

IT Interview Practice · Accepted Answer

Рассматривайте приложение как **offline-first**: каждое устройство — это локальная **реплика**. Учебные действия записываются в **локальную БД** плюс в append-only **op log** (outbox); при восстановлении соединения устройство **отправляет свои ops** и **забирает изменения сервера** с момента последней синхронизации. Конфликты разрешаются **не** одним глобальным правилом, а **семантикой каждого поля данных**.

**Ментальная модель:** думайте об этом как о **git** — каждое устройство «коммитит» локально, пока находится офлайн, а синхронизация — это **merge**, а не перезапись.

## Архитектура

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

- **Локальная БД + op log:** каждое изменение — это **неизменяемая op с id, сгенерированным на клиенте** + версия, поставленная в очередь, пока устройство офлайн. UI читает/пишет локально, поэтому остаётся плавным без сети.
- **Сервис синхронизации:** **cursor-based delta**-синхронизация — отправляет ops с момента клиентского cursor, забирает изменения новее него. Каждая синхронизация переносит только **delta**, а не весь набор данных → 5M пользователей остаётся дёшево.
- **Разрешение конфликтов:** мержит по смыслу каждого поля (ниже). **Сервер является source of truth**; клиент разрешает первым ради плавности, затем сервер повторно применяет **тот же** детерминированный merge.

## Разрешение конфликтов (суть)

Часы телефонов **ненадёжны**, и два устройства могут редактировать одну запись офлайн, поэтому **«last write wins» (LWW) молча теряет данные**. Разрешайте по семантике:

- **Монотонные поля** (прогресс урока) → берём **max**.
- **Аддитивные счётчики** (общее время обучения) → **прибавляем delta** (CRDT-подобный grow-only counter).
- **Настоящее «последнее состояние»** (позиция прокрутки) → LWW допустим.

```js
// у op есть id -> применяем идемпотентно (повторы не считаются дважды). clientTs НЕ доверяем.
function mergeProgress(server, op) {
  return {
    // progress только растёт -> max: поздняя старая op никогда не тянет его назад
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs — аддитивный счётчик -> прибавляем delta, не перезаписываем
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Здесь обычный LWW позволил бы устаревшему устройству, синхронизирующемуся с опозданием с `progress: 0.3`, **перезаписать** серверные `0.9` → потерянный прогресс. Взятие `max` и суммирование `studiedMs` делают синхронизацию **независимой от порядка** — безопасно, когда миллионы устройств синхронизируются с расхождением часов.

## Взгляд интервьюера

Интервьюер проверяет, понимаете ли вы, что **клиентским часам нельзя доверять** (то есть не чистый timestamp LWW), делаете ли вы **синхронизацию идемпотентной** (op ids) и **мержите ли по смыслу данных**. **Слабый** ответ: «используем timestamps, last write wins». **Сильный** ответ: реплика + op log + идемпотентность + merge по каждому полю + сервер как source of truth — и явное называние **потери данных** у LWW как её слабого места.

## Компромиссы

LWW дёшев, но теряет данные; семантический merge требует обдумывания каждого поля, но **ничего не теряет**. Прибегайте к полноценным **CRDT/OT** только когда вам нужно настоящее совместное редактирование (заметки, документы) — это дорого, поэтому не используйте это для всего подряд.

Архитектура

Разрешение конфликтов (суть)

Взгляд интервьюера

Компромиссы

Похожие вопросы