Tracking de envíos en tiempo real: arquitectura e implementación

Por qué el tracking importa más de lo que parece

El tracking de envíos empezó como una funcionalidad de atención al cliente: el cliente quiere saber dónde está su paquete. Pero ha evolucionado hacia algo mucho más estratégico. Un sistema de tracking en tiempo real bien implementado no solo responde “dónde está mi envío” sino que alimenta la optimización operativa: detección de anomalías en rutas, estimación de tiempos de llegada, activación de procesos downstream (preparación de muelle, documentación aduanera, facturación) y generación de datos para análisis histórico.

El problema es que la mayoría de los sistemas de tracking que encontramos en empresas logísticas 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 almacén, llegada a hub, salida a destino, entrega. Eso da 4-6 puntos de datos por envío. Un sistema en tiempo real con GPS da un punto cada 30-60 segundos, lo que cambia fundamentalmente la visibilidad y las posibilidades de optimización.

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 arquitectónicos serios. Este artículo describe la arquitectura que hemos implementado y validado.

Arquitectura general

El sistema tiene cinco capas:

Fuentes → Ingestion → Procesamiento → Almacenamiento → Presentacion

Fuentes. Dispositivos GPS en vehículos (trackers OBD-II o dispositivos dedicados como Teltonika FMB920), apps móviles 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).

Ingestión. Capa que recibe los datos de todas las fuentes, normaliza el formato y los publica en un bus de eventos. Es el punto crítico: si la ingestión falla, todo el sistema queda ciego.

Procesamiento. Lógica de negocio en tiempo real: geofencing (detectar cuando un vehículo entra/sale de una zona), cálculo de ETA, detección de anomalías (detención no planificada, desviación de ruta, velocidad anómala), y correlación de eventos (asociar la posición GPS con el envío correcto).

Almacenamiento. Doble capa: hot storage para el estado actual (donde está cada envío ahora mismo) y cold storage para el histórico (todas las posiciones de todos los envíos).

Presentación. Dashboards operativos, página de tracking pública para el cliente, notificaciones automáticas y APIs para integración con otros sistemas (TMS, ERP, plataformas de ecommerce).

Event sourcing: la decisión arquitectónica clave

La decisión arquitectónica más importante es tratar cada actualización de posición como un evento inmutable en vez de actualizar el “estado actual” del envío 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 qué esto importa:

• Auditoría completa. Puedes reconstruir exactamente lo que pasó con un envío en cualquier momento. Cuando un cliente reclama que su paquete llegó tarde, puedes mostrar el recorrido completo con timestamps.
• Reprocesamiento. Si descubres un error en la lógica de cálculo de ETA, puedes reprocesar los eventos históricos con la lógica corregida sin perder datos.
• Múltiples vistas. El mismo flujo de eventos alimenta el dashboard operativo, las notificaciones al cliente, el análisis histórico y la facturación. Cada consumidor lee los eventos que necesita sin afectar a los demás.

La implementación: 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 elección correcta para esta escala. Para operaciones más pequeñas (< 50 vehículos), Amazon SQS o Redis Streams pueden ser suficientes y significativamente más simples de operar.

Ingestión GPS: el primer cuello de botella

Un dispositivo GPS reportando cada 30 segundos genera 2.880 puntos al día. Con una flota de 200 vehículos, eso son 576.000 puntos diarios, o 6.7 puntos por segundo. Con 1.000 vehículos, 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 comunicación

Los trackers GPS envían datos vía TCP/UDP usando protocolos propietarios. Los más comunes:

• Codec 8 Extended (Teltonika): protocolo binario eficiente. Un paquete con posición, velocidad, altitud y 10 parámetros adicionales ocupa 80-100 bytes.
• MQTT: usado por apps móviles y algunos trackers modernos. Más flexible, overhead ligeramente mayor.
• HTTP/REST: el más simple para integración con apps. Mayor overhead, pero más fácil de depurar y mantener.

La capa de ingestión consiste en un servidor que habla los protocolos de los trackers, decodifica los paquetes, normaliza el formato a un esquema común y publica en Kafka.

Implementación: un servicio Python con asyncio para manejar múltiples 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 producción para una empresa de logística con 350 vehículos:

Métrica	Valor
Puntos GPS/segundo (pico)	18
Puntos GPS/día	980.000
Latencia ingestión (p95)	380ms
Latencia end-to-end (GPS → dashboard)	1.8s
Disponibilidad del servicio de ingestión	99.94% (último trimestre)

El cuello de botella no es el procesamiento sino la conectividad de los dispositivos. En zonas rurales o túneles, los trackers almacenan posiciones en buffer y las envían en ráfaga cuando recuperan conexión. El sistema debe manejar estos bursts sin degradar la latencia para el tráfico normal.

Geofencing: el multiplicador de valor

El geofencing (detección de entrada/salida de zonas geográficas predefinidas) transforma datos de posición 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 “vehículo AB-1234-CD ha entrado en zona de descarga del Puerto de Sevilla a las 14:23” es accionable.

Implementación

Las geofences se definen como polígonos (GeoJSON). Los puntos críticos para una empresa logística: almacenes, puertos, terminales de carga, direcciones de clientes frecuentes, zonas de restricción de tráfico, fronteras.

Para cada posición GPS, el sistema evalúa si el punto está dentro de alguna geofence activa. El algoritmo clásico es ray casting (O(n) donde n es el número de vértices del polígono), pero con cientos de geofences necesitas un índice espacial.

Usamos PostGIS (extensión 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 evaluación a un servicio en memoria con la librería 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 vehículo entra o sale de una geofence, se genera un evento. Tipos comunes:

• ENTER_WAREHOUSE: dispara preparación de carga/descarga.
• EXIT_WAREHOUSE: confirma salida del envío, actualiza ETA del siguiente punto.
• ENTER_PORT: notifica al agente de aduanas, prepara documentación.
• ENTER_DELIVERY_ZONE: notifica al destinatario con ETA preciso.
• EXIT_ROUTE: anomalía de ruta, alerta al operador.

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

Cálculo de ETA: el Santo Grial del tracking

Los clientes no quieren saber dónde está su envío. Quieren saber cuándo llega. El ETA (Estimated Time of Arrival) es la métrica más valiosa y la más difícil de calcular con precisión.

Modelo básico

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

Modelo con datos históricos

Entrenar un modelo con datos de entregas anteriores en la misma ruta: hora de salida, día de la semana, condiciones meteorológicas, duración real. Random Forest o Gradient Boosting con estas features da una precisión de +/- 15-25 minutos.

Modelo con datos en tiempo real

Incorporar tráfico en tiempo real (Google Maps Platform o HERE API), posición actual del vehículo, y paradas restantes. Recalcular cada 5 minutos. Precisión: +/- 8-15 minutos.

En la práctica, el modelo híbrido (histórico + tiempo real) es el que mejor funciona. El histórico proporciona la baseline; el tiempo real la corrige continuamente. El coste de las APIs de tráfico (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 vehículo está en la misma carretera que hace 5 minutos, no recalculamos la ruta.

Notificaciones: el último metro

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

Eventos que disparan notificaciones:

Evento	Destinatario	Canal
Envío recogido	Remitente	Email
En tránsito	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 envío está en tránsito” es informativo. Un SMS de “su envío llegará entre las 14:00 y 15:00” cuando el cliente está esperando un paquete es operativo. La diferencia en satisfacción del cliente entre ambos es significativa.

Implementación: los eventos de geofence y los recálculos de ETA alimentan un servicio de notificaciones que decide qué enviar, a quién y por qué canal. Usamos templates por idioma y tipo de evento. El envío se realiza vía 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 envíos en tiempo real. Lo que mostramos:

Mapa en tiempo real. Posición de todos los vehículos activos con código de color: verde (en ruta, sin anomalías), amarillo (retraso menor), rojo (anomalía: detenido > 30 min, fuera de ruta, sin señal > 1 hora).

Panel de alertas. Anomalías activas ordenadas por severidad. Cada alerta tiene un botón de “reconocer” para que el operador confirme que está al tanto y acción recomendada.

Tabla de envíos. Lista de todos los envíos activos con estado, ETA, último evento y transportista. Filtrable por ruta, cliente, prioridad y estado.

KPIs operativos. Puntualidad (% de envíos entregados dentro del ETA), tiempo medio de entrega por ruta, número de anomalías por día, tiempo de resolución de incidencias.

Tecnología: Grafana para los paneles de métricas operativas. Para el mapa en tiempo real, un componente React con Mapbox GL JS que consume posiciones vía WebSocket (actualización cada 5 segundos). La fuente de datos para el mapa es Redis, que almacena la última posición de cada vehículo como un hash.

Almacenamiento: hot y cold

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

• vehicle:{id}:position → última posición conocida (lat, lng, timestamp, speed, heading).
• shipment:{id}:status → estado actual del envío (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 vehículos simultáneamente.

Cold storage (histórico). TimescaleDB (PostgreSQL con extensión de series temporales) para todas las posiciones GPS. Con compresión habilitada, 1 millón de puntos GPS (cada uno con 15 campos) ocupan aproximadamente 80 MB. Para una flota de 500 vehículos durante un año, el almacenamiento total es de unos 500 GB, gestionable en una instancia de base de datos estándar.

Las queries históricas típicas: “muestra el recorrido completo del envío X”, “calcula el tiempo medio de tránsito Madrid-Barcelona en los últimos 6 meses”, “identifica las paradas no planificadas de más de 20 minutos en la ruta Y.”

TimescaleDB con sus hypertables e índices temporales resuelve estas queries en segundos incluso sobre meses de datos. Para escalas mayores (> 5.000 vehículos), ClickHouse o Apache Druid ofrecen mejor rendimiento en queries analíticas sobre volúmenes masivos.

Integración con carriers externos

No todos los envíos viajan en vehículos propios. Cuando un envío 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 envía eventos cuando el estado del envío cambia. La opción preferida: baja latencia, sin polling. DHL Express, FedEx y UPS ofrecen webhooks.
• API de polling. Tu sistema consulta periódicamente 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 límites de rate de la API (típicamente 1 consulta cada 5-15 minutos por envío).

El reto: cada carrier tiene su propia taxonomía de estados. “En tránsito” en DHL no significa exactamente lo mismo que en FedEx. La capa de normalización mapea los estados de cada carrier a tu taxonomía interna unificada.

Rendimiento end-to-end

Benchmarks reales de nuestro despliegue en producción:

Métrica	Objetivo	Real
Latencia GPS → Kafka	< 500ms	380ms (p95)
Latencia Kafka → geofence event	< 200ms	120ms (p95)
Latencia geofence → notificación	< 5s	3.2s (p95)
Latencia GPS → dashboard	< 3s	1.8s (p95)
Throughput ingestión	> 50 msg/s	85 msg/s (max probado)
Disponibilidad	> 99.9%	99.94%

El sistema opera en Railway con 3 servicios principales (ingestión, procesamiento, API), una instancia de Kafka gestionada (Confluent Cloud), Redis gestionado, y TimescaleDB. El coste mensual total para 350 vehículos y ~1M puntos GPS/día es de aproximadamente 450 EUR, incluyendo hosting, Kafka y APIs de tráfico.

Para flotas más grandes, la arquitectura escala horizontalmente: más particiones en Kafka, más instancias del servicio de procesamiento, y sharding en TimescaleDB. No hemos probado más allá de 2.000 vehículos simulados, donde el throughput de ingestión llega a 180 msg/s sin degradación.

El tracking en tiempo real no es un lujo. Es la infraestructura sobre la que se construyen operaciones logísticas inteligentes. Para entender cómo estos eventos de tracking alimentan flujos de automatización más amplios, consulta nuestro artículo sobre arquitectura event-driven para logística. Sin datos de posición, todo lo demás (optimización de rutas, ETAs precisos, detección de anomalías, automatización de procesos) es imposible.