En Colombia el internet se cae. No solo en zonas rurales: en pleno centro de una ciudad grande se va el proveedor. Si tu software necesita conexión para funcionar y tú dependes de ese software para operar, cada caída de internet es una caída de tu negocio.

Ese fue el problema que nos tocó resolver para un cliente institucional con sedes en zonas de conectividad inestable, donde había que identificar personas y procesar transacciones en tiempo real con cero margen de error. La solución —arquitectura offline-first— aplica para cualquier negocio que necesite seguir funcionando cuando el internet dice "no más".

## El principio: el internet es un lujo, no un requisito

La mayoría del software asume que siempre hay conexión. En Colombia esa suposición es un error de diseño. La inversión correcta es al revés: los datos se guardan primero localmente y se sincronizan cuando es posible. A partir de ahí, todo se ordena en cuatro componentes.

## 1. Base de datos local cifrada

En vez de depender de un servidor remoto, cada punto de operación tiene su propia base de datos local. En nuestro sistema crítico usamos SQLite, pero no un SQLite normal: cada registro sensible va cifrado con AES-256 antes de tocar el disco. Si alguien se roba el equipo, no puede leer los datos sin la llave. Los datos biométricos, además, son datos sensibles bajo la Ley 1581/2012 — no pueden estar en texto plano, y punto.

Esa base local aguanta hasta 48 horas de operación continua sin sincronizar. Registros, transacciones, identificaciones: todo se guarda localmente primero, y la respuesta al usuario llega en menos de un segundo sin importar el estado de la red.

## 2. Cola de sincronización

Cada operación que se hace offline se encola. Cuando vuelve la conexión, la cola se procesa automáticamente: el sistema detecta que hay internet, envía los datos pendientes al servidor central y confirma que llegaron. El usuario no hace nada.

La cola tiene estados claros —pendiente, sincronizando, sincronizado, fallido— y reintentos para los que fallan. Un registro nunca se borra de la cola hasta que el servidor confirma que lo recibió.

## 3. Resolución de conflictos

¿Qué pasa si dos puntos modificaron el mismo registro mientras estaban offline? El sistema tiene reglas de prioridad. En general gana el último en sincronizar, pero con registro completo de la versión anterior. Nada se pierde, nada se sobrescribe sin respaldo. Esa es la diferencia entre offline-first hecho bien y un "modo sin conexión" improvisado que corrompe datos en la primera colisión.

## 4. Actualizaciones verificadas

El software se actualiza por un canal verificado con SHA-256. Cada actualización trae un hash que el sistema comprueba antes de aplicar. Si el hash no coincide, la actualización se rechaza. Esto evita que alguien inyecte código malicioso en una actualización, y permite distribuir nuevas versiones sin visita presencial.

## Dónde más aplica

Esto no es solo para sistemas institucionales. Piensa en:

Un punto de venta en un centro comercial donde el WiFi se satura en diciembre. La caja sigue funcionando, el cierre se hace normal, y cuando vuelve el internet todo se sincroniza. Una clínica veterinaria en un pueblo con internet satelital que se cae con la lluvia. Historias clínicas, citas y tratamientos siguen funcionando offline. Un equipo de ventas en campo que consulta inventario y registra pedidos en zonas sin cobertura, y sube todo al llegar a una zona con señal. Un restaurante durante un corte de luz que afecta al router pero no a la tablet con batería. El POS sigue tomando pedidos.

En todos, el principio es el mismo. La arquitectura offline-first no es nueva ni difícil. Es poco común porque la mayoría del software se diseña asumiendo conexión permanente. En Colombia, ese supuesto cuesta ventas y cuesta confianza.

Si tu operación se cae cada vez que se cae el internet, no tiene que ser así. Escríbenos al wa.me/573172946935 o a [email protected].