La respuesta corta
Una app de reparto no falla en el centro de Madrid: falla en el sótano de un párking, en un polígono, en un ascensor y en la última planta de un almacén de acero. Y falla en el peor momento, que es justo cuando el repartidor entrega.
El diseño correcto no es «guardar en local y subir cuando haya red». Es decidir, función por función, qué tiene que funcionar sin cobertura, y aceptar que eso convierte el móvil en la fuente de verdad temporal de una parte del negocio.
La pregunta que ordena todo el proyecto: si el repartidor entrega un paquete a las 11:04 sin cobertura y el cliente llama a las 11:10 preguntando, ¿qué contesta el centro de control?
Qué tiene que funcionar sin red
Esto se decide en una tabla, con negocio delante, y se escribe en el alcance:
| Función | Sin cobertura |
|---|---|
| Ver la ruta y las paradas del día | Imprescindible |
| Ver datos del destinatario y observaciones | Imprescindible |
| Registrar entrega, incidencia o ausencia | Imprescindible |
| Capturar firma y fotos | Imprescindible |
| Escanear bultos | Imprescindible |
| Reasignar paradas | Requiere red |
| Ver el estado de otro repartidor | Requiere red |
| Cobrar contra reembolso | Depende del método |
Lo que hay debajo de esa tabla es la decisión real: todo lo marcado como imprescindible tiene que estar descargado antes de salir, y eso implica un momento explícito de preparación de jornada, con su indicador de «listo para salir sin red».
La cola de eventos, no el estado
El error más caro es sincronizar estados: mandar «esta parada está entregada». Cuando dos fuentes tocan lo mismo, gana la última en llegar y se pierde información.
Lo que funciona es sincronizar eventos, en orden y con identidad propia:
- Cada acción del repartidor genera un evento con identificador único generado en el dispositivo, marca de tiempo y su posición en la secuencia.
- La cola se envía en orden y el servidor los aplica con idempotencia: recibir dos veces el mismo evento no puede duplicar nada.
- El servidor responde con lo que aceptó, y el dispositivo marca esos eventos como confirmados.
Con eso, una reconexión parcial —tres eventos suben, se corta, el resto después— no deja el sistema inconsistente.
Sobre los mecanismos de resolución cuando dos partes editan lo mismo a la vez, la conversación de fondo está en sincronización offline-first con CRDT. Para reparto, la mayoría de conflictos se evitan antes: un evento de entrega lo genera una sola persona en un solo dispositivo, y el resto son consultas.
El tiempo: dos relojes que no coinciden
Hay dos momentos y no son el mismo: cuándo ocurrió y cuándo se supo. Los dos hay que guardarlos.
Y hay que decidir de quién es el reloj bueno. El del dispositivo se puede cambiar a mano, se desajusta y cambia de zona horaria. Lo habitual es guardar el instante del dispositivo junto con un desfase medido contra el servidor en la última sincronización, para poder corregir después sin perder el dato original.
En un negocio donde el compromiso de entrega es contractual, esto no es un detalle: es la prueba.
Fotos: el 90 % del volumen
Las fotos de prueba de entrega son casi todo el peso de la sincronización, y merecen su propio diseño:
- Comprimir en el dispositivo, con una calidad decidida por negocio y no por el móvil.
- Cola separada de la de eventos, con menor prioridad: primero sube el hecho, después la imagen.
- Subir por trozos y reanudar, porque la cobertura en ruta va y viene.
- Política de purga: cuánto tiempo se conservan en el dispositivo después de confirmarse. Un terminal lleno a media tarde es una incidencia real.
- Solo con Wi-Fi si el plan de datos lo exige, con la consecuencia de que la prueba llega al final del turno.
Qué ve el centro de control
Aquí es donde el diseño offline se nota fuera de la app. La torre de control tiene que distinguir tres cosas que suelen mostrarse igual:
- Entregado y confirmado.
- Entregado según el dispositivo, aún no sincronizado.
- Sin noticias — puede estar entregado, puede no estarlo.
Si la interfaz muestra igual el tercer caso y el primero, el equipo de atención al cliente dará información falsa, que es exactamente el problema que la app venía a resolver.
Batería y dispositivo
En reparto, el consumo es requisito funcional. Una app que no llega al final del turno provoca que el repartidor apague funciones, y ahí se pierde la trazabilidad.
- Muestreo de posición adaptado al estado —en marcha, parado, entregando—, no constante.
- Sin trabajo en segundo plano que no aporte.
- Probado en el dispositivo real de la flota, que casi nunca es un teléfono de gama alta.
Antes de estimar
- ¿Qué funciones son imprescindibles sin red? Con negocio, en una tabla.
- ¿Cuántas paradas y cuántas fotos por jornada? Eso dimensiona todo.
- ¿Qué dispositivo usa la flota y con qué plan de datos?
- ¿Quién es la fuente de verdad si el sistema central y el dispositivo discrepan?
- ¿Qué se le enseña al cliente final mientras un evento no ha sincronizado?
La cuarta y la quinta son de negocio y son las que más código determinan.
Es el trabajo de fondo en apps de logística y transporte y en apps offline-first: que la operación no dependa de la cobertura, porque la cobertura no depende de nadie.
