5 AM en un yacimiento: offline-first en serio

Son las cinco de la mañana en un yacimiento petrolero en el medio de la Patagonia, entre Neuquén y Chubut. Hace un frío que te rompe la cara y todavía está completamente oscuro. Llega la cuadrilla del primer turno. Un operario baja de la camioneta, camina hacia un kiosko Android de 600 dólares que está atornillado a una pared de chapa, y apoya el dedo índice. El dispositivo tiene una pantalla de 7 pulgadas y una cámara frontal. El operario tiene polvo en la campera, las manos sucias y guantes de trabajo asomando en el bolsillo.

El lector biométrico hace su trabajo: pita, la pantalla se clava en un verde brillante, registra la entrada y el tipo sigue su camino hacia la maquinaria. Todo pasa en menos de un cuarto de segundo para no frenar la fila de treinta compañeros que vienen atrás.

En ese yacimiento, la conexión a internet va y viene. A veces hay un 4G inestable, a veces hay un satelital que se corta cuando hay ráfagas de viento fuerte, y a veces no hay absolutamente nada.

Si yo armara este sistema asumiendo que el mundo es una oficina en San Francisco con WiFi de fibra óptica, el kiosko intentaría hacer un POST asíncrono a una API RESTful por cada operario que apoya el dedo. ¿Qué pasa cuando se cae la conexión? El request da un timeout. El operario que fichó a las 5 AM, muerto de frío y en horario, no queda registrado en el sistema. A fin de mes, esa falla de arquitectura de software se traduce en horas extras no pagadas, un conflicto directo y violento con el sindicato, y una multa millonaria de AFIP por inconsistencias en la liquidación de sueldos.

Yo construyo SaaS B2B que toca el mundo físico, no MVPs para que otros developers los usen desde una Mac en un café. Y el mundo físico es hostil.

El anti-claim del buen diseño en la trinchera

En nuestra industria hay una desconexión brutal entre lo que consideramos "buenas prácticas" y lo que necesita un usuario operando en la calle. Hoy abrís cualquier tutorial o le tirás un prompt a un agente de IA y te arma una interfaz bellísima.

Pero en el contexto de una obra en construcción o un yacimiento, el "buen frontend" no pasa por integrar animaciones fluidas con Framer Motion ni por tener transiciones de opacidad elegantes. El buen frontend es que la pantalla devuelva un VERDE GRANDE o un ROJO GRANDE en menos de 200 milisegundos. La latencia visual es crítica: si el sistema tarda un segundo en responder, el operario duda, vuelve a poner el dedo, el sistema procesa dos veces, y mientras tanto el compañero de atrás se impacienta porque hace tres grados bajo cero.

La "buena UX" (experiencia de usuario) no es un modal con esquinas redondeadas. Es diseñar un botón de confirmación en la interfaz que sea tan groseramente grande que se pueda apretar usando un guante de trabajo sucio sin equivocarse.

Y lo más importante: el "buen offline" no es armar una Progressive Web App (PWA) con un Service Worker decorativo que te muestra un cartelito gris de "Estás desconectado" mientras cachea tres imágenes. El buen offline es una arquitectura de supervivencia basada en colas de sincronización robustas, probadas a sangre y fuego con cortes de red de tres días consecutivos.

Arquitectura de supervivencia: resolviendo la desconexión

Para que el kiosko de FirmaLaboral sobreviva a estas condiciones, tuvimos que descartar la dependencia del tiempo real. La aplicación del kiosko, construida sobre Ionic y AngularJS, asume por defecto que internet es el enemigo y que va a fallar siempre.

Toda la carga operativa ocurre de manera local. En lugar de pegarle a nuestra API en Node, la aplicación escribe cada fichaje directamente en una base local usando IndexedDB.

La validación biométrica también ocurre offline. No subimos biometría cruda a la nube en el momento del fichaje porque un POST pesado con datos de huella fallaría constantemente. Lo que hacemos es sincronizar hacia el dispositivo un caché cifrado con los templates biométricos de los operarios autorizados para ese centro de costo. Cuando el tipo pone el dedo, el match se calcula localmente en milisegundos. Si da positivo, guardamos el registro del fichaje junto con una foto del operario capturada en el momento (clave para procesos de fraud detection) en la base local.

En paralelo, corre un proceso en background administrando una cola de sincronización. Este proceso vigila el estado de la red. Cuando detecta que internet volvió, no escupe todos los fichajes de golpe. Empaqueta los datos en batches (lotes) y empieza a enviarlos. Si la red es intermitente y el envío falla, no entra en un loop infinito que destruiría la batería del dispositivo; utiliza un algoritmo de retry exponencial. Falla la primera, espera dos segundos. Falla la segunda, espera cuatro. Falla la tercera, espera ocho.

Incluso tuvimos que integrar telemetría de hardware cruda: si la batería del kiosko baja del 15% por un corte de luz en la casilla de control, el dispositivo manda una alerta urgente de supervivencia al backend antes de apagarse, forzando un batch sync final con la energía que le queda.

El impacto asíncrono en el backend

Del otro lado del alambrado está nuestra infraestructura. Cuando internet vuelve a un yacimiento grande después de un corte de seis horas, no recibimos un fichaje. Recibimos el impacto de cinco kioskos sincronizando cientos de registros al mismo tiempo contra nuestra API.

Ahí es donde el backend en Node, encapsulado en contenedores Docker y orquestado en DigitalOcean, tiene que atajar el golpe. La base de datos, un cluster de MongoDB gestionado vía Mongoose, no puede dudar.

Acá es donde aparecen los problemas de concurrencia severa. ¿Qué pasa si el kiosko mandó el batch, Mongo lo guardó perfectamente, pero la conexión se cortó un microsegundo antes de que nuestro servidor le devolviera el 200 OK de confirmación? El kiosko asume que el envío falló. Dos horas después, vuelve internet y el kiosko reintenta mandar exactamente los mismos fichajes.

Si la API fuera ingenua, duplicaría el horario de entrada de toda la cuadrilla. Para evitar esto, la capa de persistencia implementa un patrón de resolución de conflictos rígido. Usamos un lockfile lógico y constraints compuestos (índices únicos en MongoDB cruzando el ID interno del dispositivo, el timestamp del fichaje y el ID del operario) para evitar duplicados entre kioskos del mismo cliente. La operación atómica en la base de datos es la última barrera de defensa. Si el dato ya existe, Mongo lo rechaza a nivel motor, la API captura el error de duplicación, lo trata como un éxito y le dice al kiosko: "Ya lo tenía, borralo tranquilo de tu IndexedDB".

El código y la calle

Llevo siete años construyendo y evolucionando FirmaLaboral. Llevamos más de seis años operando este sistema en producción continua, y hoy respaldamos la operación crítica de recursos humanos de más de 400 PyMEs en Argentina y Uruguay.

Esas empresas no son startups buscando rondas de inversión. Son fábricas metalúrgicas, depósitos de logística pesada, obras en construcción, yacimientos petroleros, empresas de seguridad privada y cooperativas rurales. Son negocios donde la fricción física es la norma y donde una falla de software detiene la operación de gente que madruga mucho.

Tengo 52 años y llevo casi 40 años de oficio peleando con sistemas, arquitecturas y bases de datos. He visto pasar muchísimas modas, frameworks y herramientas que prometen revolucionar cómo construimos productos. La velocidad de la IA hoy para generar código es espectacular, y la uso todos los días.

Pero si algo te enseña este nivel de exposición al mundo físico, es que el código más prolijo, moderno y hermoso en tu repositorio de GitHub no vale absolutamente nada si no es capaz de aguantar un turno de invierno a las cinco de la mañana en Neuquén.