Sensor telemetry into an operator console with a 3D spatial view, for radioactive material storage. Tech lead and architect.
Context
A nuclear research center operating a research reactor and radioactive material storage needed continuous visibility of its storage areas. A report produced after the fact does not serve that. An operator has to be able to watch the storage while the readings are still arriving.
Sensors publish over MQTT into Quarkus and Jakarta EE services, running in containers on Kubernetes and OpenShift that the center operates itself. The console is Angular. It carries operational dashboards and a 3D view that puts every reading where it physically is.
The spatial view does real work. A list of sensor identifiers asks the operator to hold the layout of the building in their head and match rows to rooms. Rendering each reading in place removes that step, so an anomalous value arrives already attached to a location.
The platform began with my promotion to senior in May 2025 and is still in active development.
The data path, end to end. Every reading takes this route and no other.
Constraints
The team had years of Angular between them and no React at all.
Sensors get added. Whatever routing scheme shipped first would have to absorb hardware nobody had specified yet, without renaming everything already publishing.
It runs on infrastructure the center operates itself, so nothing could assume a managed cloud service was available.
The foundations went in before most of the team did. The people who arrived later would inherit those decisions without having been in the room for them.
Decisions
Angular with Three.js for the 3D view
Instead of
react-three-fiber
Why
react-three-fiber is the more capable option and the more widely adopted one. Taking it would have put the 3D view, the surface hardest to debug and hardest to hand over, into a framework nobody on the team had written a line of. On a system reporting on radioactive storage, I weighted the team's ability to maintain it above the framework's capability.
What it cost
Two costs. Three.js is plain JavaScript, so it arrived untyped and un-Angular, and adapters and wrappers had to be written before anyone could work in it comfortably. The larger cost is that the Three.js ecosystem has reorganized itself around React. The examples, the answers and the recipes are written for react-three-fiber, so almost nothing could be lifted, and every pattern had to be re-derived in Angular.
One MQTT topic hierarchy, fixed per sensor and per zone
Instead of
Each team naming topics for the services it owns
Why
We agreed the shape across teams as an RFC before the first message was published. The topic encodes zone and sensor, so where a reading belongs can be derived from the topic itself instead of looked up in a table somebody has to keep current. A device that did not exist when the scheme was written still has exactly one place its data can go.
What it cost
Everyone had to agree on the shape before anyone could publish, and then hold to it. Correcting a hierarchy once devices are in the field is expensive, so the agreement had to be reached at the point where the least was known.
Set the architecture and the service boundaries before the team grew
Instead of
Start smaller and let the structure emerge as engineers joined
Why
An engineer joining a platform with defined boundaries can be handed a surface to work on. Joining one that has not settled means every task carries an architectural argument first. I spent the opening months fixing the data path end to end, covering ingestion, persistence and what the console reads, so that the work arriving afterwards was feature work.
What it cost
I drew the boundaries before the people who would live inside them had a say. What offsets that is written reasoning. A boundary that turns out wrong can be argued with on the record.
What runs where. Broker, services and store sit inside a cluster the center operates itself; the console is the only surface an operator touches.
What I owned
Tech lead and architect. I set the system architecture and the service boundaries, and defined the data path end to end, from sensor ingestion through to what the console renders. The foundations were mine alone before other engineers came onto the platform. From there the work was technical direction, the code-review standards the team holds to, and mentoring on the patterns underneath them. The MQTT hierarchy was mine to negotiate across teams.
Outcome
What I was asked for was foundations, and that is what the platform has. The team extends it without me in the room. A new sensor lands in a known place, and the console's hardest surface is written in the framework the team is strongest in.
Engineers who joined after the architecture was set ship on it without needing me to explain where things go.