Real-time telemetry dashboard at Ericsson
Cut training energy by 20% across four Dockerized modules with 95% test coverage. Aug–Dec 2024.
Ericsson · Aug–Dec 2024
title: 'Real-time telemetry dashboard at Ericsson' summary: 'Cut training energy by 20% across four Dockerized modules with 95% test coverage. Aug–Dec 2024.' role: 'Software Developer' organization: 'Ericsson' period: 'Aug–Dec 2024' stack: ['Python', 'Angular', 'Express', 'MQTT', 'Docker'] repoStatus: 'none'
Context
Distributed training runs spin up many workers in parallel. Without live visibility into each node, operators have no good way to steer the run or notice when something is burning cycles for nothing. Ericsson’s brief was to fix that — a real-time dashboard fed from the workers themselves, plus the inter-service plumbing under it and the test discipline that would let it run unattended.
I owned the full software surface: design, implementation, containerization, and testing across the four-module application stack. The training algorithms themselves were not my work — the engineering around them was.
What I built
- Dashboard surface — a real-time view of training rounds, with a Python telemetry backend feeding metrics into an Angular frontend through an Express bridge over MQTT.
- Inter-service communication — four Docker containers wired together with an MQTT broker as the data-flow backbone, secured per-service so each module authenticated independently.
- Test discipline — 95% automated coverage from day one, validating program reliability and surfacing vulnerabilities before they reached production.
Decisions and trade-offs
MQTT over REST for telemetry
Distributed training rounds emit a continuous stream of small events from many workers at once. A pub/sub broker fits that shape; a polling REST loop wastes energy and adds latency at exactly the boundary the project was trying to optimize. The MQTT broker also kept each service decoupled — workers publish, the dashboard subscribes, no service needs to know who is on the other end.
Angular for the dashboard
Angular was both my strongest frontend stack and the one that lined up with the existing tooling on the team. Picking the second-best framework would have meant either a learning curve in the middle of a four-month engagement or a frontend that other engineers could not maintain.
95% coverage as a gate, not a goal
Coverage was wired into CI before the first feature shipped, which kept the testable surface small and forced design choices that were easy to verify. Treating coverage as an after-the-fact target produces brittle suites; treating it as a build gate keeps the architecture honest.
Outcome
A 20% reduction in training energy over a baseline run on the same workload graph. The dashboard, the four containers, and the test suite are the artifacts that made that number repeatable.
Stack
Python · Angular · Express · MQTT · Docker