Transport operations and telemetry platform
Transport operations platform serving multiple client environments and integrating with vehicle tracking hardware.
Anonymized case study: client names, infrastructure data, and sensitive details have been omitted for confidentiality.
Context
A transport operations and telemetry platform with a legacy PHP codebase, isolated client environments, and continuous ingestion of data from equipment installed in vehicles. The system cannot stop: transport operations depend on it in real time.
Challenge
Evolve and modernize a continuously running system without interrupting the business. Coupling between modules made every change risky, telemetry ingestion competed for resources with the web application, and the volume accumulated in MariaDB degraded operational queries.
My role
Senior Software Engineer, with architecture-level responsibility over backend, database, and production infrastructure.
Responsibilities
- Maintenance and modernization of legacy PHP applications.
- Backend APIs and domain modules.
- Telemetry ingestion and processing.
- Production troubleshooting.
- High-volume MariaDB/MySQL databases.
- Containerized services.
- Workers and scheduled tasks.
- Monitoring and operational reliability.
Constraints
- Business-critical system: short maintenance windows and controlled releases.
- Large legacy codebase with tightly coupled modules.
- Isolated environments per client.
- Continuous telemetry ingestion, with no tolerance for silent data loss.
- A full rewrite was never a viable option.
Architecture
- Incremental modernization via Strangler Fig: new modules alongside the legacy code, gradually hollowing out the monolith.
- Separation of telemetry ingestion from the web application, so data spikes could not take down the operational interface.
- Asynchronous workers for processing outside the request cycle.
- Containerized services on Docker Swarm, with deployment more predictable than the previous on-premises model.
- Maintenance and partitioning routines on the fastest-growing tables.
Main technical decisions
Modernize with Strangler Fig instead of rewriting the system.
Why
The system underpins daily operations. A rewrite would mean freezing features for months and betting on a single cutover, with no guaranteed feature parity against years of business rules implicit in the legacy code.
Trade-offs
- Prolonged coexistence of new and legacy code, with duplicated maintenance during the transition.
- Requires discipline about boundaries. Without it, the legacy spreads back in.
- Architectural gains arrive gradually, which is politically harder to justify than a rewrite project.
Isolate telemetry ingestion from the web application.
Why
Ingestion and the operational interface have completely different load profiles. Sharing a process meant a telemetry spike degraded the experience of the people actually running transport operations.
Trade-offs
- More components to operate and monitor.
- Introduces inter-process communication where there used to be a direct call.
- Clear fault-isolation gain: an ingestion problem no longer takes operations down.
Adopt Docker Swarm rather than heavier orchestration.
Why
The need was to organize deployments and gain operational visibility on infrastructure coming from on-premises. Swarm delivered that with a learning curve the existing team and operation could absorb.
Trade-offs
- Smaller ecosystem and fewer advanced features than the alternatives.
- A decision fitted to that context and that team, not a universal recommendation.
Implementation
- Refactoring of coupled modules, extracting responsibilities behind explicit boundaries.
- Workers and scheduled tasks, with structured logs for troubleshooting.
- Redis supporting cache and coordination of asynchronous routines.
- Routing between the legacy and the new services.
Production concerns
- Incident investigation grounded in logs and metrics rather than guesswork.
- Controlled releases with a rollback path.
- Monitoring of asynchronous routines. A silently failing worker is the most expensive failure mode in this kind of system.
Results
- Reduced operational coupling by separating telemetry ingestion from the web application.
- More organized and more visible deployments after moving to container-based services.
- Sustained high-volume telemetry processing in a continuously running production environment.
- Improved legacy maintainability through incremental refactoring, without interrupting operations.
Stack
- PHP
- MariaDB
- MySQL
- Redis
- Docker Swarm
- Linux