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)
◧◨
The first time I worked with message brokers was on a GPS device project. What came before was a legacy project with heavy coupling in its code, so when devices updated their firmware and could send messages with new frames or other alert types, it was extremely hard — a task that should have been simple. Adding new behaviors was a real headache. On top of that, there was a growing, documented bottleneck that degraded database reads because of the high write volume from these devices sending hundreds of messages, affecting report generation and real-time dashboard queries — for something so critical to a company with a fleet distributed across Mexico.
Modular redesign with event-driven architecture
Much of the approach for this redesign came from the Modern Architecture course taught by Domingo Suárez (@domix), whose decoupling concepts guided me to the solution.
I designed a modular Spring Boot project with three modules: the core with simple tasks, domain models, and so on; one in charge of handling the GPS connection and publishing events to a Kafka cluster; and finally one dedicated entirely to processing events for writing GPS messages to a database.
The advantage of the topic layout and the module dedicated to consuming these events was that concurrency, message durability, and integrity were easy to scale and guarantee.
Applying design patterns when necessary
As I mentioned earlier, one of the main problems came up when adding new message types that GPS devices could send. To solve it, I applied the Strategy design pattern (https://refactoring.guru/es/design-patterns/strategy). The clarity of this implementation made it easy to add new behaviors without extra complexity, keeping a uniform base structure while each strategy handled its own business logic.
Jib for containerizing Java applications?
To close out the project, deployment was simple using Jib to build the image for each module. That kept consistency and decoupling when building and distributing the project in a Jenkins pipeline. It is also optimized for incremental builds, rebuilding only what changes, and its pom configuration is very simple, letting you publish the image to an internal repository or Docker Hub without requiring a Docker daemon.
2 years later — what now?
After ~2 years of implementation and deployment:
- The data volume processed is more than 4 million events per week.
- Read and write operations stabilized, and latency percentiles stay healthy and predictable.
- The impact on user experience improved substantially: shorter wait times for analytical reports, reliable real-time dashboards, and better alerting systems.
In the end, decoupling the transport layer from processing through events not only solved the technical bottleneck — it turned a rigid codebase into a resilient, easy-to-extend platform.
References
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