Offline-first no es una función: es una arquitectura
Cómo diseñar una cola de escritura idempotente para que una app siga funcionando cuando se cae la red.
Escrito por KillaQ
En Lima, en un ascensor, en el metro o en una zona con cobertura irregular, la red no es un detalle: es la condición normal. Una app que asume conectividad permanente no falla de vez en cuando — falla justo cuando el usuario más la necesita.
El error de tratar offline como un estado de error
La implementación habitual envuelve cada petición en un try/catch, muestra "sin conexión" y pierde lo que el usuario acababa de escribir. Eso no es soportar offline: es informar de que no se soporta.
Offline-first invierte la relación. La fuente de verdad para el usuario es el dispositivo. La red es un mecanismo de sincronización que puede tardar, fallar o llegar en desorden.
La cola de salida
El patrón central es una cola de escritura persistente:
- La acción del usuario se aplica de inmediato al estado local y se persiste.
- La intención se encola como una operación con identificador propio.
- Un proceso en segundo plano vacía la cola cuando hay red, con reintentos y espera exponencial.
- La respuesta del servidor concilia el estado local.
Lo importante es que el paso 1 nunca dependa del paso 3.
Idempotencia o duplicados
Si el cliente reenvía una operación porque no recibió la respuesta —no porque no llegara al servidor—, se duplica. La solución no es adivinar: es que el cliente genere un identificador único por operación y el servidor lo trate como clave. La segunda vez que llega el mismo identificador, el servidor devuelve el resultado original en lugar de crear otro registro.
Sin eso, una red intermitente produce comprobantes duplicados, cobros repetidos y pedidos fantasma.
Conflictos: decide antes de que ocurran
Dos dispositivos editan el mismo registro sin conexión. Cuando ambos suben, alguien gana. "Último en escribir gana" es una decisión válida si es explícita; deja de serlo cuando es accidental.
Para la mayoría de casos de negocio, el mejor enfoque es evitar el conflicto por diseño: operaciones que suman en lugar de sobrescribir, y campos con propietario claro.
Qué probar
Ninguna de estas garantías se verifica con buena conectividad. Prueba en modo avión a mitad de una escritura, con la app cerrada durante la sincronización, y con el reloj del dispositivo desajustado. Ahí es donde aparecen los duplicados.