Diseña la sincronización offline para una app de aprendizaje: ¿cómo resuelves los conflictos?

Question

IT Interview Practice · Accepted Answer

Trata la app como **offline-first**: cada dispositivo es una **réplica** local. Las acciones de estudio se escriben en una **DB local** más un **op log** (outbox) de solo anexado; al reconectar, el dispositivo **envía sus ops** y **descarga los cambios del servidor** desde su última sincronización. Los conflictos se resuelven **no** con una única regla global sino por la **semántica de cada campo de datos**.

**Modelo mental:** piénsalo como **git** — cada dispositivo hace "commit" localmente mientras está offline, y la sincronización es un **merge**, no una sobrescritura.

## Arquitectura

```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 cambio es una **op inmutable con un id generado por el cliente** + versión, encolada mientras está offline. La UI lee/escribe localmente, por lo que se mantiene fluida sin red.
- **Servicio de sync:** sincronización **delta basada en cursor** — envía las ops desde el cursor del cliente, descarga los cambios más recientes que este. Cada sincronización mueve solo el **delta**, no todo el dataset → 5M de usuarios sigue siendo barato.
- **Resolvedor de conflictos:** hace merge según el significado de cada campo (abajo). El **servidor es la fuente de la verdad**; el cliente resuelve primero para la fluidez, y luego el servidor reaplica el **mismo** merge determinista.

## Resolución de conflictos (el núcleo)

Los relojes de los teléfonos son **poco fiables** y dos dispositivos pueden editar el mismo registro offline, así que **"last write wins" (LWW) pierde datos de forma silenciosa**. Resuelve por semántica:

- **Campos monótonos** (progreso de la lección) → toma el **máximo**.
- **Contadores aditivos** (tiempo total de estudio) → **suma el delta** (contador grow-only estilo CRDT).
- **Verdadero "último estado"** (posición del scroll) → LWW es aceptable.

```js
// la op tiene un id -> aplicar de forma idempotente (los reintentos no cuentan doble). clientTs NO es de fiar.
function mergeProgress(server, op) {
  return {
    // progress solo aumenta -> max: una op vieja y tardía nunca lo arrastra hacia atrás
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs es un contador aditivo -> suma el delta, no sobrescribas
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

Aquí, un LWW simple dejaría que un dispositivo obsoleto que sincroniza tarde con `progress: 0.3` **sobrescriba** el `0.9` del servidor → progreso perdido. Tomar `max` y sumar `studiedMs` hace que la sincronización sea **independiente del orden** — seguro cuando millones de dispositivos sincronizan con relojes desfasados.

## Enfoque de entrevista

El entrevistador está sondeando si sabes que **no se puede confiar en los relojes del cliente** (por lo que no un LWW puro por timestamp), si haces la **sincronización idempotente** (ids de op), y si haces **merge según el significado de los datos**. Una respuesta **débil**: "usa timestamps, last write wins". Una respuesta **fuerte**: réplica + op log + idempotencia + merge por campo + servidor como fuente de la verdad — y nombrar explícitamente el fallo de **pérdida de datos** de LWW.

## Trade-offs

LWW es barato pero pierde datos; el merge semántico requiere pensar campo por campo pero **no pierde nada**. Recurre a **CRDT/OT** completos solo cuando necesitas verdadera edición colaborativa (notas, documentos) — es costoso, así que no lo uses para todo.

Arquitectura

Resolución de conflictos (el núcleo)

Enfoque de entrevista

Trade-offs

Preguntas relacionadas