Soluti: arquitectura para un centro de distribución
Diseño y desarrollo de la arquitectura completa de un centro de distribución: ruteo optimizado, tracking en tiempo real y trazabilidad operativa de punta a punta.
- Rol
- Fundador y CTO
- Industria
- Logística
- Stack técnico
- Ruby on Rails, Next.js, Flutter, PostgreSQL/PostGIS, MongoDB, NATS, VROOM, OSRM
Contexto
Soluti opera como centro de distribución en Colombia, ofreciendo cross-docking, almacenamiento y recolección para operadores logísticos. Como fundador y responsable técnico, diseñé la arquitectura completa del sistema desde cero: no existía una plataforma previa que extender, sino un proceso operativo real que debía convertirse en software confiable desde el primer día de producción.
El reto
Un centro de distribución no es una sola aplicación, sino varios sistemas que deben permanecer sincronizados bajo presión operativa real: administración interna, coordinadores en bodega, conductores en ruta y clientes rastreando sus envíos, todos operando sobre el mismo estado de verdad en tiempo real.
Tres problemas concretos definieron la arquitectura:
- Ruteo de última milla. Optimizar decenas de paradas por vehículo no es un problema que se resuelve con un algoritmo de libro de texto; es un problema de asignación con restricciones geográficas y de capacidad que crece de forma combinatoria.
- Estado compartido en tiempo real. La posición de un conductor, el estado de un paquete y la disponibilidad de una ruta cambian constantemente y deben reflejarse de inmediato en tres aplicaciones distintas.
- Trazabilidad de extremo a extremo. Cada paquete debe poder rastrearse desde que un proveedor lo entrega hasta que llega a su destinatario final, con evidencia fotográfica y documentos válidos para facturación.
La arquitectura
El sistema se diseñó como un monorepo multi-aplicación: una API en Ruby on Rails como fuente de verdad, y tres frontends (landing pública, aplicación de operador y aplicación de cliente) desplegados de forma independiente.
Ruteo. En lugar de construir un motor de optimización propio, integré VROOM y OSRM autogestionados, usando PostGIS para cálculos geoespaciales y afinidad de zonas. La decisión de ingeniería aquí no fue "cómo optimizo rutas", sino "cuándo tiene sentido apoyarse en herramientas especializadas en vez de reinventarlas". La reducción de distancias de última milla vino de la integración correcta, no de un algoritmo propio.
Tiempo real. Un microservicio dedicado usa NATS como bus de eventos y MongoDB para almacenar telemetría GPS con expiración por TTL, evitando que datos de posición de bajo valor a largo plazo saturen la base de datos principal.
Mobile. La aplicación de conductores se construyó en Flutter, con GPS en segundo plano, escaneo de códigos de barras y sincronización de paquetes en ruta, usando Riverpod para manejo de estado y go_router para navegación.
Trazabilidad. El modelo de datos cubre toda la cadena Proveedor → Operación → Envío → Paquete → Ruta, con generación de documentos listos para facturación y almacenamiento de evidencia fotográfica en MinIO, autogestionado sobre OVH.
Decisiones que marcaron la diferencia
- Priorizar herramientas de ruteo probadas (VROOM/OSRM) sobre construir un solver propio, liberando tiempo de ingeniería para el resto del sistema.
- Separar el estado de tiempo real (NATS + MongoDB con TTL) de los datos transaccionales de negocio (PostgreSQL), evitando que un problema de escala afectara al otro.
- Diseñar la trazabilidad desde el modelo de datos, no como una capa de reportes añadida después.