学習アプリのオフライン同期を設計してください。コンフリクトはどのように解決しますか？

Question

IT Interview Practice · Accepted Answer

アプリを **offline-first** として扱う。各デバイスはローカルな **replica** である。学習アクションは **ローカル DB** と追記専用の **op log**（outbox）に書き込まれ、再接続時にデバイスは **自分の ops を push** し、前回の同期以降の **サーバー変更を pull** する。コンフリクトは単一のグローバルなルールで **なく**、**各データフィールドの意味（semantics）** によって解決する。

**メンタルモデル:** **git** のように考える。各デバイスはオフライン中にローカルで「commit」し、同期は上書きではなく **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)
```

- **ローカル DB + op log:** 各変更は **クライアント生成の id を持つ immutable な op** ＋ version であり、オフライン中はキューに入る。UI はローカルで読み書きするため、ネットワークなしでも滑らかに保たれる。
- **Sync サービス:** **cursor-based delta** 同期 — クライアントの cursor 以降の ops を push し、それより新しい変更を pull する。各同期は全データセットではなく **delta** だけを動かす → 5M ユーザーでも安く済む。
- **コンフリクト解決器:** フィールドごとの意味に基づいて merge する（下記）。**サーバーが source of truth** であり、クライアントは滑らかさのため先に解決し、その後サーバーが **同じ** 決定的な merge を再適用する。

## コンフリクト解決（中核）

スマホの時計は **信頼できず**、2 台のデバイスが同じレコードをオフラインで編集し得るため、**「last write wins」（LWW）は静かにデータを失う**。semantics に基づいて解決する:

- **Monotonic なフィールド**（lesson の progress）→ **max** を取る。
- **加算カウンター**（総学習時間）→ **delta を加える**（CRDT スタイルの grow-only counter）。
- **真の「最新状態」**（scroll 位置）→ 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` を **上書き** させてしまう → progress の喪失。`max` を取り `studiedMs` を合算すれば同期は **順序に依存しない** ものになり、何百万台ものデバイスがずれた時計で同期しても安全になる。

## 面接の視点

面接官は、あなたが **クライアントの時計は信頼できない**（だから純粋な timestamp LWW ではない）ことを知っているか、**同期を idempotent にする**（op id）か、**データの意味に基づいて merge する**かを見ている。**弱い** 回答:「timestamp を使って last write wins」。**強い** 回答: replica + op log + idempotency + フィールドごとの merge + source of truth としてのサーバー — そして LWW の **データ損失** という失敗を明示的に指摘すること。

## トレードオフ

LWW は安いが失いやすい。semantic merge はフィールドごとの検討が要るが **何も失わない**。真の共同編集（notes、documents）が必要なときだけ完全な **CRDT/OT** に手を伸ばす — コストが高いので、すべてに使ってはいけない。

アーキテクチャ

コンフリクト解決（中核）

面接の視点

トレードオフ

関連する質問