Desenhe a sincronização offline para uma app de aprendizagem: como resolve conflitos?

Question

IT Interview Practice · Accepted Answer

Trate a app como **offline-first**: cada dispositivo é uma **réplica** local. As ações de estudo são escritas numa **DB local** mais um **op log** apenas de anexação (outbox); ao reconectar, o dispositivo **envia as suas ops** e **puxa as alterações do servidor** desde a última sincronização. Os conflitos são resolvidos **não** por uma regra global única, mas pela **semântica de cada campo de dados**.

**Modelo mental:** pense nisto como **git** — cada dispositivo "faz commit" localmente enquanto está offline, e a sincronização é um **merge**, não uma sobreposição.

## Arquitetura

```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 local + op log:** cada alteração é uma **op imutável com um id gerado pelo cliente** + versão, colocada em fila enquanto offline. A UI lê/escreve localmente, por isso mantém-se fluida sem rede.
- **Serviço de sincronização:** sincronização **delta baseada em cursor** — envia as ops desde o cursor do cliente, puxa as alterações mais recentes do que ele. Cada sincronização move apenas o **delta**, não o conjunto de dados inteiro → 5M de utilizadores continua barato.
- **Resolvedor de conflitos:** faz merge pelo significado de cada campo (abaixo). O **servidor é a source of truth**; o cliente resolve primeiro para fluidez, depois o servidor reaplica o **mesmo** merge determinístico.

## Resolução de conflitos (o cerne)

Os relógios dos telemóveis são **pouco fiáveis** e dois dispositivos podem editar o mesmo registo offline, portanto **o "last write wins" (LWW) perde dados silenciosamente**. Resolva pela semântica:

- **Campos monótonos** (progresso da lição) → tome o **máximo**.
- **Contadores aditivos** (tempo total de estudo) → **some o delta** (contador grow-only ao estilo CRDT).
- **Verdadeiro "estado mais recente"** (posição de scroll) → LWW é aceitável.

```js
// op tem um id -> aplica de forma idempotente (retries não contam a dobrar). clientTs NÃO é de confiança.
function mergeProgress(server, op) {
  return {
    // progress só aumenta -> max: uma op antiga e atrasada nunca o puxa para trás
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs é um contador aditivo -> soma o delta, não sobrepõe
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Aqui, o LWW simples deixaria um dispositivo desatualizado que sincroniza tarde com `progress: 0.3` **sobrepor** o `0.9` do servidor → progresso perdido. Tomar o `max` e somar `studiedMs` torna a sincronização **independente da ordem** — segura quando milhões de dispositivos sincronizam com relógios desalinhados.

## Perspetiva de entrevista

O entrevistador está a testar se sabe que **os relógios do cliente não são de confiança** (logo, não é LWW puro por timestamp), se torna a **sincronização idempotente** (op ids) e se faz **merge pelo significado dos dados**. Uma resposta **fraca**: "usar timestamps, last write wins." Uma resposta **forte**: réplica + op log + idempotência + merge por campo + servidor como source of truth — e nomear explicitamente a falha de **perda de dados** do LWW.

## Compromissos

O LWW é barato mas com perdas; o merge semântico exige reflexão por campo mas **não perde nada**. Recorra a **CRDT/OT** completo apenas quando precisa de verdadeira edição colaborativa (notas, documentos) — é dispendioso, por isso não o use para tudo.

Arquitetura

Resolução de conflitos (o cerne)

Perspetiva de entrevista

Compromissos

Perguntas relacionadas