Plataforma de operaciones de transporte y telemetría
Plataforma de operaciones de transporte con múltiples entornos de cliente e integración con equipos de rastreo vehicular.
Case study anonimizado: nombres de cliente, datos de infraestructura y detalles sensibles se han omitido por confidencialidad.
Contexto
Plataforma de operaciones y telemetría de transporte, con base de código heredada en PHP, entornos aislados por cliente e ingesta continua de datos procedentes de equipos instalados en los vehículos. El sistema no puede detenerse: la operación de transporte depende de él en tiempo real.
Desafío
Evolucionar y modernizar un sistema en operación continua sin interrumpir el negocio. El acoplamiento entre módulos hacía arriesgado cualquier cambio, la ingesta de telemetría competía por recursos con la aplicación web, y el volumen acumulado en MariaDB degradaba las consultas operativas.
Mi papel
Senior Software Engineer, con responsabilidades de arquitectura sobre backend, base de datos e infraestructura de producción.
Responsabilidades
- Mantenimiento y modernización de las aplicaciones heredadas en PHP.
- APIs backend y módulos de dominio.
- Ingesta y procesamiento de telemetría.
- Investigación de problemas en producción.
- Bases MariaDB/MySQL de alto volumen.
- Servicios en contenedores.
- Workers y tareas programadas.
- Monitorización y fiabilidad operativa.
Restricciones
- Sistema business-critical: ventanas de mantenimiento cortas y releases controladas.
- Base heredada extensa, con módulos fuertemente acoplados.
- Entornos aislados por cliente.
- Ingesta de telemetría continua, sin tolerancia a pérdida silenciosa de datos.
- Una reescritura completa nunca fue una opción viable.
Arquitectura
- Modernización incremental vía Strangler Fig: módulos nuevos junto al legado, vaciando el monolito poco a poco.
- Separación de la ingesta de telemetría de la aplicación web, para que los picos de datos no tumbaran la interfaz operativa.
- Workers asíncronos para el procesamiento fuera del ciclo de request.
- Servicios en contenedores sobre Docker Swarm, con despliegue más predecible que el modelo on-premises anterior.
- Rutinas de mantenimiento y particionado en las tablas de mayor crecimiento.
Principales decisiones técnicas
Modernizar con Strangler Fig en lugar de reescribir el sistema.
Por qué
El sistema sostiene la operación diaria. Una reescritura exigiría congelar funcionalidades durante meses y apostar por un corte único, sin paridad funcional garantizada frente a años de reglas de negocio implícitas en el legado.
Trade-offs
- Convivencia prolongada entre código nuevo y heredado, con mantenimiento duplicado durante la transición.
- Exige disciplina de fronteras: sin ella, el legado vuelve a extenderse.
- La ganancia arquitectónica llega de forma gradual, más difícil de justificar políticamente que un proyecto de reescritura.
Aislar la ingesta de telemetría de la aplicación web.
Por qué
Ingesta e interfaz operativa tienen perfiles de carga completamente distintos. Compartiendo proceso, un pico de telemetría degradaba la experiencia de quien estaba operando el transporte.
Trade-offs
- Más componentes que operar y monitorizar.
- Introduce comunicación entre procesos donde antes había una llamada directa.
- Ganancia clara de aislamiento de fallos: un problema en la ingesta deja de tumbar la operación.
Adoptar Docker Swarm en lugar de una orquestación más pesada.
Por qué
La necesidad era organizar despliegues y ganar visibilidad operativa en una infraestructura que venía de on-premises. Swarm lo entregó con una curva de aprendizaje asumible por el equipo y la operación existentes.
Trade-offs
- Ecosistema menor y menos funciones avanzadas que las alternativas.
- Una decisión adecuada a ese contexto y a ese equipo, no una recomendación universal.
Implementación
- Refactorización de módulos acoplados, extrayendo responsabilidades tras fronteras explícitas.
- Workers y tareas programadas, con logs estructurados para troubleshooting.
- Redis como apoyo para caché y coordinación de rutinas asíncronas.
- Enrutamiento entre los servicios heredados y los nuevos.
Operación en producción
- Investigación de incidentes basada en logs y métricas, no en suposiciones.
- Releases controladas, con rollback previsto.
- Monitorización de las rutinas asíncronas. Un worker que falla en silencio es el modo de fallo más caro en este tipo de sistema.
Resultados
- Redujo el acoplamiento operativo al separar la ingesta de telemetría de la aplicación web.
- Despliegues más organizados y con mayor visibilidad tras la migración a servicios en contenedores.
- Sostuvo el procesamiento de telemetría de alto volumen en un entorno de producción continua.
- Mejoró la mantenibilidad del legado mediante refactorización incremental, sin interrumpir la operación.
Stack
- PHP
- MariaDB
- MySQL
- Redis
- Docker Swarm
- Linux