Construcción de una plataforma de rastreo en tiempo real
Diseño y evolución de una plataforma backend capaz de procesar datos GPS continuos mientras respalda lógica de negocio, reportes y notificaciones en tiempo real.
Antes de construir, necesitaba comprender el sistema.
La plataforma procesa datos GPS continuos de vehículos y convierte ese flujo en información que el resto del producto puede usar: rastreo, eventos, reportes, notificaciones y actualizaciones en tiempo real.
Cuando comenzó la nueva versión de la plataforma, el primer desafío no fue la implementación. Fue entender cómo funcionaba el producto existente, cómo se relacionaban sus módulos y qué debía lograr la nueva versión.
Dediqué la etapa inicial a comprender funcionalmente el sistema, probando sus módulos y relaciones antes de trabajar a fondo con el código.
El desafío no era recibir datos GPS. Era convertir un flujo continuo en un producto confiable.
La versión anterior de la plataforma tenía un modelo de procesamiento más simple. La nueva versión debía soportar significativamente más lógica de negocio mientras mantenía la capacidad de respuesta al crecer el volumen de datos de rastreo.
Un solo rastreo podía activar validación, cálculos, detección de eventos, persistencia, actualizaciones de estado, reportes y notificaciones en tiempo real.
Eso significaba que las decisiones de arquitectura no podían tomarse alrededor de una operación aislada. Debían considerar el flujo de procesamiento completo y cómo cada componente afectaba al resto del sistema.
Los datos de rastreo llegan continuamente, no como solicitudes aisladas.
El procesamiento evolucionó de la entrega básica de rastreo a la detección de eventos, cálculos y reglas de negocio.
Los reportes, notificaciones y actualizaciones debían estar disponibles sin depender del procesamiento nocturno.
La arquitectura debía soportar funcionalidad nueva sin hacer cada cambio progresivamente más costoso.
Ayudé a convertir el nuevo backend en la base de la siguiente versión de la plataforma.
Me incorporé al desarrollo inicial de la nueva versión y trabajé principalmente en el backend .NET, desde la estructura de servicios y modelado de datos hasta la lógica de negocio y el procesamiento de alto rendimiento.
En lugar de reproducir exactamente el sistema anterior, trabajé con el equipo para comprender qué necesitaba la nueva plataforma y adaptar la arquitectura y la implementación a esos requisitos.
Creé y estructuré servicios .NET de acuerdo con las responsabilidades y requisitos de cada parte de la plataforma.
Diseñé modelos y relaciones de datos, incluido el uso de PostgreSQL, MongoDB y Redis para diferentes necesidades del sistema.
Desarrollé y evolucioné el flujo responsable de validación, cálculos, detección de eventos, persistencia y acciones posteriores.
Trabajé con gRPC, RabbitMQ y comunicación en tiempo real para conectar los servicios de procesamiento con el resto de la plataforma.
Investigué tiempo de procesamiento, carga de base de datos, uso de memoria, operaciones costosas y consumo de recursos conforme crecía la plataforma.
Participé en decisiones sobre responsabilidades de servicios, arquitectura, enfoques de implementación y cómo debía encajar la nueva funcionalidad en el sistema.
Distintas responsabilidades requerían distintas herramientas.
La plataforma se diseñó como un grupo de servicios con responsabilidades diferentes. El objetivo no era introducir tecnología por sí misma, sino usar cada componente donde tuviera sentido para el problema que se resolvía.
Almacenar información procesada y mantener el estado requerido por la plataforma.
Enviar actualizaciones relevantes a las aplicaciones web y móviles.
Usado para información relacional y persistente donde las relaciones y los datos estructurados eran importantes.
Usado para información orientada al rastreo, donde un modelo de documentos se ajustaba a los patrones de acceso.
Usado cuando el acceso rápido a estado necesario frecuentemente podía reducir trabajo innecesario contra el almacenamiento persistente.
La arquitectura fue moldeada por el problema, no por la tecnología.
El objetivo no era introducir tecnología por sí misma. Cada decisión arquitectónica debía responder a un requisito, carga de trabajo o necesidad futura real de la plataforma.
Los servicios se estructuraron alrededor de responsabilidades y requisitos, en lugar de dividir la plataforma simplemente para tener más microservicios.
PostgreSQL, MongoDB y Redis se usaron para distintos tipos de datos y necesidades de acceso, en lugar de forzar cada carga a un mismo modelo de almacenamiento.
RabbitMQ se usó donde el trabajo podía desacoplarse del flujo principal, permitiendo a los servicios comunicarse sin que cada operación dependiera de una respuesta síncrona.
gRPC se usó para comunicación interna cuando las llamadas estructuradas y eficientes entre servicios eran adecuadas.
No todo problema necesitaba una solución sofisticada. El enfoque fue introducir complejidad donde aportaba un beneficio claro, manteniendo simples las partes más sencillas del sistema.
El alto rendimiento hace costosas las pequeñas ineficiencias.
A medida que aumentaba la cantidad de datos de rastreo, el rendimiento no podía tratarse como una sola métrica. El tiempo de procesamiento, carga de base de datos, consumo de memoria y operaciones costosas afectaban la capacidad del sistema para seguir el ritmo de la carga entrante.
El objetivo no era simplemente hacer más rápidas las operaciones individuales. Era reducir trabajo innecesario en todo el flujo de procesamiento conservando el mismo resultado de negocio.
Comprender el flujo de procesamiento completo y dónde encaja cada operación en el sistema.
Revisar tiempo de procesamiento, consumo de recursos, actividad de base de datos, asignaciones y comportamiento de memoria.
Identificar de dónde provenía el costo real en lugar de optimizar según suposiciones.
Separar cálculos costosos, operaciones de base de datos, transformaciones y rutas intensivas en memoria.
Reducir consultas innecesarias, operaciones costosas, tamaños de objetos y trabajo repetido cuando fuera apropiado.
Verificar que el flujo optimizado siguiera produciendo el mismo resultado de negocio bajo cargas realistas.
eventos de rastreo procesados por segundo
con menos trabajo innecesario y consumo de recursos
reduciendo presión sobre procesamiento, bases de datos e infraestructura
La nueva plataforma se convirtió en la base de la siguiente etapa del producto.
La nueva versión se lanzó y adoptó progresivamente en México, Colombia y Estados Unidos. La plataforma respaldó la migración de usuarios de la versión anterior al tiempo que introducía capacidades no disponibles en el sistema original.
El resultado no fue solo un backend más nuevo. Fue una plataforma capaz de procesar datos de rastreo en tiempo real, generar reportes, detectar eventos y activar notificaciones como parte del flujo normal de procesamiento.
La información de rastreo, eventos, reportes y notificaciones se convirtieron en parte de un modelo de procesamiento en tiempo real.
La nueva plataforma se desplegó para operaciones en México, Colombia y Estados Unidos.
El backend evolucionó para manejar cargas que alcanzaban aproximadamente 7,000–8,000 eventos de rastreo por segundo.
Las optimizaciones de procesamiento y memoria redujeron el consumo innecesario de recursos y la infraestructura requerida para respaldar la plataforma.
La plataforma introdujo funcionalidades como rastreo de rutas, reportes en tiempo real, notificaciones configurables, viajes y características operativas adicionales.
La arquitectura proporcionó una base donde nuevos requisitos de negocio podían incorporarse sin reconstruir la plataforma ante cada cambio.
La parte más difícil no fue construir el sistema. Fue comprenderlo lo suficiente para hacerlo evolucionar.
Trabajar en un sistema que procesa datos continuos a alto volumen cambió mi forma de pensar sobre ingeniería backend. Rendimiento, arquitectura, datos y lógica de negocio no pueden tratarse como preocupaciones aisladas cuando forman parte del mismo flujo de procesamiento.
También aprendí que comprender el sistema existente no es tiempo que se dedica antes del desarrollo. Es parte del desarrollo mismo. Cuanto mejor comprendo el problema y su contexto, mayor es mi confianza en la solución y en las compensaciones que implica.