Tracking de envios en tiempo real: arquitectura e implementacion

Por que el tracking importa mas de lo que parece

El tracking de envios empezo como una funcionalidad de atencion al cliente: el cliente quiere saber donde esta su paquete. Pero ha evolucionado hacia algo mucho mas estrategico. Un sistema de tracking en tiempo real bien implementado no solo responde “donde esta mi envio” sino que alimenta la optimizacion operativa: deteccion de anomalias en rutas, estimacion de tiempos de llegada, activacion de procesos downstream (preparacion de muelle, documentacion aduanera, facturacion) y generacion de datos para analisis historico.

El problema es que la mayoria de los sistemas de tracking que encontramos en empresas logisticas medianas no son realmente en tiempo real. Son sistemas de estado que se actualizan cuando alguien escanea un bulto en un punto de control: salida de almacen, llegada a hub, salida a destino, entrega. Eso da 4-6 puntos de datos por envio. Un sistema en tiempo real con GPS da un punto cada 30-60 segundos, lo que cambia fundamentalmente la visibilidad y las posibilidades de optimizacion.

Construir un sistema de tracking en tiempo real no es trivial. El volumen de datos, la heterogeneidad de fuentes y la necesidad de baja latencia crean retos arquitectonicos serios. Este articulo describe la arquitectura que hemos implementado y validado.

Arquitectura general

El sistema tiene cinco capas:

Fuentes → Ingestion → Procesamiento → Almacenamiento → Presentacion

Fuentes. Dispositivos GPS en vehiculos (trackers OBD-II o dispositivos dedicados como Teltonika FMB920), apps moviles de conductores (Android/iOS con GPS nativo), scanners en puntos de control (almacenes, hubs), APIs de carriers externos (DHL, FedEx, UPS proporcionan webhooks o APIs de tracking), y sensores IoT en contenedores (temperatura, humedad, apertura de puertas).

Ingestion. Capa que recibe los datos de todas las fuentes, normaliza el formato y los publica en un bus de eventos. Es el punto critico: si la ingestion falla, todo el sistema queda ciego.

Procesamiento. Logica de negocio en tiempo real: geofencing (detectar cuando un vehiculo entra/sale de una zona), calculo de ETA, deteccion de anomalias (detencion no planificada, desviacion de ruta, velocidad anomala), y correlacion de eventos (asociar la posicion GPS con el envio correcto).

Almacenamiento. Doble capa: hot storage para el estado actual (donde esta cada envio ahora mismo) y cold storage para el historico (todas las posiciones de todos los envios).

Presentacion. Dashboards operativos, pagina de tracking publica para el cliente, notificaciones automaticas y APIs para integracion con otros sistemas (TMS, ERP, plataformas de ecommerce).

Event sourcing: la decision arquitectonica clave

La decision arquitectonica mas importante es tratar cada actualizacion de posicion como un evento inmutable en vez de actualizar el “estado actual” del envio directamente. Event sourcing significa que almacenas todos los eventos (posicion_reportada, escaneo_realizado, geofence_activado, anomalia_detectada) en una secuencia ordenada, y el estado actual se deriva de esa secuencia.

Por que esto importa:

• Auditoria completa. Puedes reconstruir exactamente lo que paso con un envio en cualquier momento. Cuando un cliente reclama que su paquete llego tarde, puedes mostrar el recorrido completo con timestamps.
• Reprocesamiento. Si descubres un error en la logica de calculo de ETA, puedes reprocesar los eventos historicos con la logica corregida sin perder datos.
• Multiples vistas. El mismo flujo de eventos alimenta el dashboard operativo, las notificaciones al cliente, el analisis historico y la facturacion. Cada consumidor lee los eventos que necesita sin afectar a los demas.

La implementacion: Apache Kafka como bus de eventos. Cada tipo de evento tiene su topic (gps_positions, scan_events, geofence_events). Los productores publican eventos; los consumidores los procesan.

Kafka es la eleccion correcta para esta escala. Para operaciones mas pequenas (< 50 vehiculos), Amazon SQS o Redis Streams pueden ser suficientes y significativamente mas simples de operar.

Ingestion GPS: el primer cuello de botella

Un dispositivo GPS reportando cada 30 segundos genera 2.880 puntos al dia. Con una flota de 200 vehiculos, eso son 576.000 puntos diarios, o 6.7 puntos por segundo. Con 1.000 vehiculos, 33 puntos por segundo. No es big data, pero la latencia importa: cada punto debe estar disponible para procesamiento en menos de 2 segundos.

Protocolo de comunicacion

Los trackers GPS envian datos via TCP/UDP usando protocolos propietarios. Los mas comunes:

• Codec 8 Extended (Teltonika): protocolo binario eficiente. Un paquete con posicion, velocidad, altitud y 10 parametros adicionales ocupa 80-100 bytes.
• MQTT: usado por apps moviles y algunos trackers modernos. Mas flexible, overhead ligeramente mayor.
• HTTP/REST: el mas simple para integracion con apps. Mayor overhead, pero mas facil de depurar y mantener.

La capa de ingestion consiste en un servidor que habla los protocolos de los trackers, decodifica los paquetes, normaliza el formato a un esquema comun y publica en Kafka.

Implementacion: un servicio Python con asyncio para manejar multiples conexiones TCP concurrentes. Para trackers Teltonika, usamos un decoder open source (pyteltonica o similar). Para MQTT, Mosquitto como broker conectado a un consumidor que republica en Kafka. Para HTTP, un endpoint FastAPI.

Throughput real

En nuestro despliegue en produccion para una empresa de logistica con 350 vehiculos:

Metrica	Valor
Puntos GPS/segundo (pico)	18
Puntos GPS/dia	980.000
Latencia ingestion (p95)	380ms
Latencia end-to-end (GPS → dashboard)	1.8s
Disponibilidad del servicio de ingestion	99.94% (ultimo trimestre)

El cuello de botella no es el procesamiento sino la conectividad de los dispositivos. En zonas rurales o tuneles, los trackers almacenan posiciones en buffer y las envian en rafaga cuando recuperan conexion. El sistema debe manejar estos bursts sin degradar la latencia para el trafico normal.

Geofencing: el multiplicador de valor

El geofencing (deteccion de entrada/salida de zonas geograficas predefinidas) transforma datos de posicion en eventos de negocio. Un punto GPS que dice “latitud 37.3861, longitud -5.9925” no significa nada para un operador. Un evento que dice “vehiculo AB-1234-CD ha entrado en zona de descarga del Puerto de Sevilla a las 14:23” es accionable.

Implementacion

Las geofences se definen como poligonos (GeoJSON). Los puntos criticos para una empresa logistica: almacenes, puertos, terminales de carga, direcciones de clientes frecuentes, zonas de restriccion de trafico, fronteras.

Para cada posicion GPS, el sistema evalua si el punto esta dentro de alguna geofence activa. El algoritmo clasico es ray casting (O(n) donde n es el numero de vertices del poligono), pero con cientos de geofences necesitas un indice espacial.

Usamos PostGIS (extension espacial de PostgreSQL) con su operador ST_Contains. PostGIS usa un R-tree index que permite evaluar miles de geofences en milisegundos. La query:

SELECT g.id, g.name, g.type
FROM geofences g
WHERE ST_Contains(g.polygon, ST_SetSRID(ST_MakePoint(-5.9925, 37.3861), 4326));

Para flujos de alta frecuencia (> 100 posiciones/segundo), movemos la evaluacion a un servicio en memoria con la libreria shapely de Python y un spatial index pre-cargado. Esto evita la latencia de la query a PostgreSQL y permite evaluar geofences en < 1ms.

Eventos de geofence

Cuando un vehiculo entra o sale de una geofence, se genera un evento. Tipos comunes:

• ENTER_WAREHOUSE: dispara preparacion de carga/descarga.
• EXIT_WAREHOUSE: confirma salida del envio, actualiza ETA del siguiente punto.
• ENTER_PORT: notifica al agente de aduanas, prepara documentacion.
• ENTER_DELIVERY_ZONE: notifica al destinatario con ETA preciso.
• EXIT_ROUTE: anomalia de ruta, alerta al operador.

Estos eventos alimentan automatizaciones downstream que eliminan horas de trabajo manual diario.

Calculo de ETA: el Santo Grial del tracking

Los clientes no quieren saber donde esta su envio. Quieren saber cuando llega. El ETA (Estimated Time of Arrival) es la metrica mas valiosa y la mas dificil de calcular con precision.

Modelo basico

Distancia restante dividida por velocidad media. Funciona para rutas simples y distancias cortas. Precision: +/- 30-60 minutos.

Modelo con datos historicos

Entrenar un modelo con datos de entregas anteriores en la misma ruta: hora de salida, dia de la semana, condiciones meteorologicas, duracion real. Random Forest o Gradient Boosting con estas features da una precision de +/- 15-25 minutos.

Modelo con datos en tiempo real

Incorporar trafico en tiempo real (Google Maps Platform o HERE API), posicion actual del vehiculo, y paradas restantes. Recalcular cada 5 minutos. Precision: +/- 8-15 minutos.

En la practica, el modelo hibrido (historico + tiempo real) es el que mejor funciona. El historico proporciona la baseline; el tiempo real la corrige continuamente. El coste de las APIs de trafico (Google Maps cuesta 5 USD por 1.000 requests a la Directions API) es el factor limitante para actualizaciones frecuentes. Usamos cache agresivo: si un vehiculo esta en la misma carretera que hace 5 minutos, no recalculamos la ruta.

Notificaciones: el ultimo metro

Un sistema de tracking sin notificaciones proactivas obliga al cliente a consultar manualmente. Las notificaciones automaticas transforman el tracking de pull (el cliente pregunta) a push (el sistema informa).

Eventos que disparan notificaciones:

Evento	Destinatario	Canal
Envio recogido	Remitente	Email
En transito	Destinatario	Email + SMS
En reparto (< 2 horas)	Destinatario	SMS + Push
Entregado	Remitente + Destinatario	Email
Incidencia (retraso, intento fallido)	Remitente	Email + SMS

El canal importa. Un email de “su envio esta en transito” es informativo. Un SMS de “su envio llegara entre las 14:00 y 15:00” cuando el cliente esta esperando un paquete es operativo. La diferencia en satisfaccion del cliente entre ambos es significativa.

Implementacion: los eventos de geofence y los recalculos de ETA alimentan un servicio de notificaciones que decide que enviar, a quien y por que canal. Usamos templates por idioma y tipo de evento. El envio se realiza via Brevo para email, Twilio para SMS y Firebase para push notifications.

Dashboard operativo: la vista del controlador

El dashboard es donde el equipo de operaciones ve el estado de todos los envios en tiempo real. Lo que mostramos:

Mapa en tiempo real. Posicion de todos los vehiculos activos con codigo de color: verde (en ruta, sin anomalias), amarillo (retraso menor), rojo (anomalia: detenido > 30 min, fuera de ruta, sin señal > 1 hora).

Panel de alertas. Anomalias activas ordenadas por severidad. Cada alerta tiene un boton de “reconocer” para que el operador confirme que esta al tanto y accion recomendada.

Tabla de envios. Lista de todos los envios activos con estado, ETA, ultimo evento y transportista. Filtrable por ruta, cliente, prioridad y estado.

KPIs operativos. Puntualidad (% de envios entregados dentro del ETA), tiempo medio de entrega por ruta, numero de anomalias por dia, tiempo de resolucion de incidencias.

Tecnologia: Grafana para los paneles de metricas operativas. Para el mapa en tiempo real, un componente React con Mapbox GL JS que consume posiciones via WebSocket (actualizacion cada 5 segundos). La fuente de datos para el mapa es Redis, que almacena la ultima posicion de cada vehiculo como un hash.

Almacenamiento: hot y cold

Hot storage (estado actual). Redis con la estructura:

• vehicle:{id}:position → ultima posicion conocida (lat, lng, timestamp, speed, heading).
• shipment:{id}:status → estado actual del envio (en_transito, en_reparto, entregado).
• shipment:{id}:eta → ETA actual.

Redis permite lecturas en < 1ms, que es lo que necesita el dashboard para actualizar 500 vehiculos simultaneamente.

Cold storage (historico). TimescaleDB (PostgreSQL con extension de series temporales) para todas las posiciones GPS. Con compresion habilitada, 1 millon de puntos GPS (cada uno con 15 campos) ocupan aproximadamente 80 MB. Para una flota de 500 vehiculos durante un ano, el almacenamiento total es de unos 500 GB, gestionable en una instancia de base de datos estandar.

Las queries historicas tipicas: “muestra el recorrido completo del envio X”, “calcula el tiempo medio de transito Madrid-Barcelona en los ultimos 6 meses”, “identifica las paradas no planificadas de mas de 20 minutos en la ruta Y.”

TimescaleDB con sus hypertables e indices temporales resuelve estas queries en segundos incluso sobre meses de datos. Para escalas mayores (> 5.000 vehiculos), ClickHouse o Apache Druid ofrecen mejor rendimiento en queries analiticas sobre volumenes masivos.

Integracion con carriers externos

No todos los envios viajan en vehiculos propios. Cuando un envio se entrega a un carrier externo (DHL, SEUR, FedEx, transporte contratado), necesitas integrar su tracking en tu sistema para ofrecer una vista unificada al cliente.

Los carriers exponen tracking de dos formas:

• Webhooks. El carrier te envia eventos cuando el estado del envio cambia. La opcion preferida: baja latencia, sin polling. DHL Express, FedEx y UPS ofrecen webhooks.
• API de polling. Tu sistema consulta periodicamente la API del carrier para obtener el estado actual. Necesario cuando el carrier no ofrece webhooks. La frecuencia de polling balancea frescura de datos con limites de rate de la API (tipicamente 1 consulta cada 5-15 minutos por envio).

El reto: cada carrier tiene su propia taxonomia de estados. “En transito” en DHL no significa exactamente lo mismo que en FedEx. La capa de normalizacion mapea los estados de cada carrier a tu taxonomia interna unificada.

Rendimiento end-to-end

Benchmarks reales de nuestro despliegue en produccion:

Metrica	Objetivo	Real
Latencia GPS → Kafka	< 500ms	380ms (p95)
Latencia Kafka → geofence event	< 200ms	120ms (p95)
Latencia geofence → notificacion	< 5s	3.2s (p95)
Latencia GPS → dashboard	< 3s	1.8s (p95)
Throughput ingestion	> 50 msg/s	85 msg/s (max probado)
Disponibilidad	> 99.9%	99.94%

El sistema opera en Railway con 3 servicios principales (ingestion, procesamiento, API), una instancia de Kafka gestionada (Confluent Cloud), Redis gestionado, y TimescaleDB. El coste mensual total para 350 vehiculos y ~1M puntos GPS/dia es de aproximadamente 450 EUR, incluyendo hosting, Kafka y APIs de trafico.

Para flotas mas grandes, la arquitectura escala horizontalmente: mas particiones en Kafka, mas instancias del servicio de procesamiento, y sharding en TimescaleDB. No hemos probado mas alla de 2.000 vehiculos simulados, donde el throughput de ingestion llega a 180 msg/s sin degradacion.

El tracking en tiempo real no es un lujo. Es la infraestructura sobre la que se construyen operaciones logisticas inteligentes. Para entender como estos eventos de tracking alimentan flujos de automatizacion mas amplios, consulta nuestro articulo sobre arquitectura event-driven para logistica. Sin datos de posicion, todo lo demas (optimizacion de rutas, ETAs precisos, deteccion de anomalias, automatizacion de procesos) es imposible.