Por qué diseñé el sistema de trazabilidad forestal para funcionar sin conexión

La mayoría de software de gestión se diseña asumiendo una conexión a internet estable. Es la asunción por defecto en casi cualquier tutorial, framework o arquitectura moderna. En una concesión forestal en el Congo o en Camerún, esa asunción simplemente no se sostiene — y diseñar como si se sostuviera es la forma más rápida de construir un sistema que nunca llega a usarse en el terreno.

El contexto que obliga a pensar distinto

Los equipos de tala trabajan a menudo a horas de cualquier punto con cobertura móvil. La electricidad, cuando existe, no es constante. Un sistema que necesita "llamar a casa" para funcionar —para autenticar a un usuario, para guardar un registro, para validar un dato— deja de funcionar en el momento exacto en que más se necesita: en el bosque, con el tronco recién talado delante.

Las decisiones de arquitectura que se derivan de ahí

• Almacenamiento local primero. Cada dispositivo de campo guarda sus propios datos de forma completa y autónoma, sin depender de que un servidor confirme nada en el momento.
• Sincronización diferida, no bloqueante. Cuando aparece conexión —en el campamento, en la carretera, al llegar al aserradero— los datos se envían en segundo plano, sin que el usuario tenga que esperar ni intervenir.
• Resolución de conflictos pensada de antemano. Si dos dispositivos capturan datos relacionados antes de sincronizar, el sistema necesita reglas claras de qué prevalece, en vez de simplemente sobrescribir o duplicar.
• Identificadores únicos generados en el dispositivo, no por una base de datos central, para que un tronco pueda tener un ID válido y definitivo desde el segundo en que se marca, sin esperar a la sincronización.

Por qué esto no es "hacer una PWA" y ya está

Existen muchas soluciones genéricas de "modo offline" en el desarrollo web moderno, y la mayoría resuelven un caso mucho más simple: una app que pierde la conexión durante unos minutos y la recupera enseguida. El escenario real aquí es distinto — días sin conexión, no minutos, y datos que tienen que llegar a ser exactos y completos incluso si la sincronización tarda semanas. Eso cambia las decisiones de fondo, desde el modelo de datos hasta cómo se comunican los errores al usuario en el propio dispositivo de campo.

Lo que esto significa para un cliente que evalúa el sistema

Si tu empresa está valorando implantar (o migrar a) un sistema de trazabilidad para EUDR, esta es la pregunta técnica que de verdad importa hacerle a cualquier proveedor: ¿qué pasa con los datos si el dispositivo pasa una semana sin conexión? La respuesta a esa pregunta dice más sobre si el sistema va a funcionar de verdad en tu terreno que cualquier lista de funcionalidades.

Hablemos de su trazabilidad EUDR