04 — CASO_DE_ESTUDIO_CASE_STUDY_
Backend modular para telemetría GPS a escala (+4M eventos/semana)Modular backend for GPS telemetry at scale (+4M events/week)
◧◨
La primera vez que trabajé con brokers de mensajería fue para un proyecto de dispositivos GPS. Los precedentes era un proyecto legacy, con mucho acoplamiento en su código, es que cuando los dispositivos actualizan su firmware y podían mandar mensajes con tramas nuevas u otros tipos de alertas, era completamente difícil, una tarea que debería ser sencilla, añadir nuevos comportamientos era realmente un dolor de cabeza, y por otra parte existía un cuello de botella registrado creciente que deterioraba las lecturas en base de datos debido a la alta escritura que se tenía por estos dispositivos que mandaban cientos de mensajes, afectando generación de reportes o consulta de dashboard en tiempo real, para algo tan crítico para una empresa que tiene su flotilla distribuida a lo largo de la República Mexicana.
Rediseño modular con arquitectura basada en eventos
Gran parte del enfoque para este rediseño lo aprendí en el curso de Arquitectura Moderna impartido por Domingo Suárez (@domix), cuyos conceptos de desacoplamiento me guiaron a la solución.
Diseñe un proyecto modular con Spring Boot. Tres módulos respectivos: el core con tareas sencillas, modelos de dominio, etc, otro encargado de manejar la conexión con los GPS y publicar los eventos a un cluster de kafka y finalmente uno dedicado enteramente al procesamiento de los eventos para las escrituras de los mensajes de GPS en una base de datos.
La ventaja del diseño del tópico y el módulo dedicado a consumir estos eventos es que era fácil escalar la concurrencia, la durabilidad de los mensajes y asegurar la integridad de los mismos.
Aplicar patrones de diseño cuando es necesario
Como mencioné previamente, uno de los principales problemas surgía al agregar nuevos tipos de mensajes que los dispositivos GPS podían enviar. Para resolver esto, apliqué el patrón de diseño Strategy (https://refactoring.guru/es/design-patterns/strategy). La claridad de esta implementación facilitó la incorporación de nuevos comportamientos sin complejidad adicional, manteniendo una estructura base uniforme mientras cada estrategia manejaba su propia lógica de negocio.
¿JIB para despliegue de contenerizar aplicaciones de Java?
Para cerrar el proyecto, el despliegue fue sencillo al usar JIB para generar las imágenes de cada módulo. Esto mantuvo la consistencia y el desacoplamiento al construir y distribuir el proyecto en un pipeline de Jenkins. Además, está optimizado para construcciones incrementales, reconstruyendo solo lo que cambia, y su configuración en el pom es muy simple, permitiendo publicar la imagen en un repositorio interno o en Docker Hub sin obligarte a usar un docker deamon.
2 años después, ¿y ahora?
Después de ~2 años de su implementación y despliegue:
- El volumen de datos que se procesan son más de 4 de millones de eventos por semana.
- Las operaciones de lectura y escritura se estabilizaron, y los percentiles de latencia se mantienen sanos y predecibles.
- El impacto en la experiencia de usuario mejoro sustancialmente, tiempos de espera cortos en generación de reportes analíticos, dashboards en tiempo real confiables y mejores sistemas de alertas.
Al final, desacoplar la capa de transporte del procesamiento mediante eventos no solo resolvió el cuello de botella técnico, sino que transformó una base de código rígida en una plataforma resiliente y fácil de extender.
Referencias
Los dispositivos GPS publican sus tramas en un cluster de Kafka. Un módulo dedicado consume los eventos, aplica la estrategia de cada tipo de mensaje y escribe en la base de datos sin acoplar el transporte al procesamiento.GPS devices publish their frames into a Kafka cluster. A dedicated module consumes the events, applies the strategy for each message type and writes to the database without coupling transport to processing.
›events 4,124,658/wk · lag=6 · consumer up