Context
This was a real-time number-plate recognition product built for environments where cameras, local infrastructure, and network conditions could not be assumed to be reliable. The recognition model was only one part of the experience. Operators still needed to add sources, start and stop them safely, see what was happening live, and keep working when a camera or connection misbehaved.
The product also had to run in constrained, on-premise environments. That made access control, offline activation, packaging, and recovery part of the backend work—not work to be figured out after delivery.
The Product Challenge
The challenge was to make a set of interdependent concerns work together: continuous video input, a usable operator experience, native-memory behavior, access control, product licensing, and offline deployment.
A camera pipeline is not a typical request-response feature. Input keeps coming, sources fail independently, and native libraries can allocate memory outside Go’s heap. Meanwhile, operators need a current, understandable view—not a system that quietly piles up stale work. The backend needed clear boundaries that made those conditions manageable.
My Scope
I designed and implemented the infrastructure around the R&D-owned recognition model. That included source lifecycle management, frame and live-delivery integration, persistence, licensing and access controls, deployment packaging, and the documentation that helped the team connect the pieces.
The R&D team owned model research, training, selection, and internals. My job was to make the model’s output useful in the product: take a controlled source and turn it into a result an authorized operator could use. Keeping that boundary explicit meant the platform could evolve without every change becoming a model change.
Making Camera Input Operable
I treated a camera or uploaded video as a managed product resource. An operator could register a source, activate it, stop it, update it, or remove it through a lifecycle that stayed separate from frame processing. That separation mattered: stopping a source had to release runtime work cleanly, not just flip a status in the interface.
Interruptions were expected. The intake path could reconnect after temporary failures and keep the rest of the service available while a source recovered. Live delivery gave operators a current view, while persistence and product integration made the result useful beyond a single transient frame.
Keeping the CGO Video Pipeline Stable
The hardest reliability problem appeared where Go met native video libraries. The Go heap could look small while process memory remained high, because OpenCV buffers and related allocations live outside the Go heap. Treating that as an ordinary garbage-collection issue would have missed the real risk.
I addressed it in two layers. First, the capture path made ownership explicit: native image and encoding buffers were reused where appropriate and closed as soon as their data had safely moved into Go-managed memory. Second, the runtime image used jemalloc to better handle a concurrent native workload with variable allocation sizes.
The result is deliberately described without numbers. Memory pressure became a design and testing concern, and camera start/stop cycles were built to leave the service in a more predictable state. It is a practical example of why CGO resource lifecycle belongs in backend reliability work.
Designing for Freshness, Not Backlog
For a live operator, an old frame can be less useful than the next one. I designed bounded, non-blocking paths so a slow consumer could fall behind without stopping source capture or every other viewer.
That was a product decision as much as an engineering one. The system did not promise to preserve every frame under pressure. It made the trade-off clear: protect a current view, make recovery visible, and do not let an unbounded backlog quietly redefine the experience.
The frame boundary itself evolved from gRPC to IPC and then to a ZeroMQ-oriented design as the constraints became clearer. The point was not to crown a winning protocol. It was to find a cleaner separation between source control and downstream work. The ZeroMQ boundary was built as a decoupled, downstream-ready path; this case study does not claim that every deployment used an active end-to-end Core AI frame stream.
Keeping an Offline Product Under Control
The product needed to stay manageable without depending on a permanent internet connection. I designed and implemented an offline activation flow that connected product entitlement to a local installation and enabled approved capabilities in a controlled way.
Licensing and user permissions answered different questions. Role-based access decided whether a user could manage a source or view a live stream. Licensing decided whether the installed product was entitled to run a capability at all. Internal services used short-lived credentials over mutually authenticated channels, so entitlement was enforced beyond the user interface.
This is not a broad security claim. It is a practical control model for the environment the product was built for: local activation, clear locked and ready states, and controlled access to product capabilities.
Release and Operations
I treated packaging and operations as part of delivery. The release path supported offline installation, local activation, health states, and backup/restore considerations. Operators could bring the system up, understand whether it was ready or locked, and recover local operational state without relying on an undocumented manual process.
The same documentation also made ownership clearer. It gave the team a shared way to reason about sources, live behavior, access, and recovery as one system instead of a collection of separate services.
What Shipped—and What Was Still Next
The platform progressed through a pilot and a production release path. Camera lifecycle control, live delivery, recovery-aware stream handling, offline activation, and controlled access were all part of the delivered platform work.
Some work was still in progress, so it is not presented as an outcome here: quantitative license limits, immediate offline revocation, fully persisted reconnect state, fully wired operational metrics, and a universally active end-to-end Core AI streaming path. Being clear about that distinction matters. It separates what the team delivered from what the next iteration needed.
Lessons Learned
I learned that real-time reliability is not only about throughput. It is about deciding what stays useful under pressure, who is allowed to act, and whether the system can actually be installed and run in its target environment.
I also learned that a healthy Go heap does not automatically mean a healthy video service, and that licensing is more than a commercial switch. In an on-premise product, memory ownership, access control, offline activation, and release operations are all part of the same backend responsibility.