Offline-first синхронизация

Offline-first синхронизация даёт читать и писать с **локальным persistence** при ненадёжной сети, затем сверяться с сервером через очереди, retries, детект конфликтов и явный degraded-mode UX. На интервью ждут границы consistency — не «кешируем API responses».

| Компонент | Роль | |-----------|------| | Local store | IndexedDB/SQLite; переживает перезапуск | | Mutation queue | Упорядоченные ops с client-generated ID | | Optimistic UI | Локально; rollback или conflict при сбое | | Sync engine | Backoff, batching, background sync (SW), connectivity listeners | | Conflict rules | Last-write-wins vs CRDT vs server merge vs UI для пользователя | | Auth & permissions | Offline reads в cached scope; writes re-validated на сервере |

					Offline edit → enqueue { opId, entityVersion, payload } → UI pending →
online → POST /sync → 409 CONFLICT → merge UI или auto-rule
				

Модели consistency: strong на сервере; клиент может быть eventually consistent. Что видит пользователь при offline-редактировании с двух устройств.

PWA: стратегии cache в service worker ≠ sync данных — не путать static assets с authoritative business data.

На интервью: collaborative todo offline на двух устройствах. Identity ops, стратегия конфликтов, удаления, тесты flaky networks.

Типовые ошибки: optimistic UI без rollback; тихая потеря данных; неограниченная очередь; sync секретов на shared devices; Background Sync API «везде».

Компромисс — мгновенность для пользователя против сложности merge и support при conflict resolution.

Чеклист:

• Client op IDs и server versioning или vector clocks.
• Видимый sync status и retry.
• Тесты с offline/online flaps.
• Сервер — authority для auth и инвариантов.