A logging service that stopped hitting its limits
A legacy logging system for a distributed simulation environment had hit hard limits on how much it could track. I helped replace it with a standards-based service, ported it to Linux, containerized it, and validated a streaming pipeline behind it.
- Client type
- Professional work
- Problem
- The legacy logging system could only track a fixed number of entities, and the environment had outgrown it. It ran on Windows, was hard to deploy consistently, and couldn’t take part in the wider distributed architecture it needed to join.
- What I built
- An HLA-based distributed logging service: ported from Windows to Linux, packaged in containers for repeatable deployment, with a Kafka pipeline validated end to end and the groundwork laid for it to join the federation as a first-class participant.
- Result
- The entity limit is gone, deployments are repeatable, and the service is positioned to integrate with the rest of the system instead of sitting beside it.
- Stack
- HLA · Linux · Containers · Kafka
Professional work, described in general terms — no programs, customers or sensitive details.
The situation
A distributed simulation environment logged what happened through a system that was built for a smaller world. It could only track a fixed number of entities, it ran on Windows while the rest of the environment was moving to Linux, and it had no clean way to participate in the standards-based architecture around it.
What I did
I worked on the replacement: a logging service built on HLA (the standard these systems use to talk to each other). I ported it from Windows to Linux, containerized it so it deploys the same way everywhere, and stood up and validated a Kafka pipeline to move the data reliably. Along the way I laid the groundwork for the service to join the federation directly rather than through a side channel.
What changed
The hard limit is gone. Deployment is a container, not a checklist. And the service is on a path to being part of the system rather than bolted onto it — which is what makes the next set of improvements possible.