Professional focus

I am a backend engineer focused on Go services for AI-driven products, real-time pipelines, APIs, microservices, and deployment-ready infrastructure. Product-facing experience helps me turn backend decisions into clear contracts and workflows that remain useful beyond the service itself.

I am especially interested in product systems where correctness, state, and operational reliability matter—whether the workflow is real-time, data-intensive, or transaction-sensitive.

In recent work on an on-premise real-time AI platform, I designed and implemented the product layer around an R&D-owned recognition model. That meant making camera and video input operable, handling native-resource pressure in a Go/CGO path, supporting controlled offline access, and helping shape the release and operations path. I did not build the model; I built the backend and product infrastructure that made its output usable.

Engineering field notes

How I move from a question to a system people can rely on.

These are the working habits behind the services I build—not a fixed recipe, but a way to make complex work clearer and more useful.

Field note 01: Observe

Field note 01 / 04

I start with the conditions the system will actually face.

Point of view
A backend decision is only useful when it reflects the real input, the surrounding workflow, and the people who rely on the result.
In practice
Before choosing an implementation, I trace the signal, constraints, and likely failure modes so the service solves the real problem—not a simplified version of it.
Where it shows up
See the real-time recognition case study — A recognition event only mattered once it could become a dependable part of an operator workflow.

A recognition event only mattered once it could become a dependable part of an operator workflow.

  1. 01 / Observe

    I start with the conditions the system will actually face.

    Point of view
    A backend decision is only useful when it reflects the real input, the surrounding workflow, and the people who rely on the result.
    In practice
    Before choosing an implementation, I trace the signal, constraints, and likely failure modes so the service solves the real problem—not a simplified version of it.
    Where it shows up
    See the real-time recognition case study — A recognition event only mattered once it could become a dependable part of an operator workflow.

    A recognition event only mattered once it could become a dependable part of an operator workflow.

  2. 02 / Map

    I give each boundary a clear job.

    Point of view
    A short note, flow, or model can turn an unclear system into a decision the team can inspect together.
    In practice
    I make ownership, delivery paths, assumptions, and failure points visible before implementation detail takes over the conversation.
    Where it shows up
    Read about evolving a frame pipeline — Transport choices become clearer when ownership, operating constraints, and product behavior are visible in the same picture.

    Transport choices become clearer when ownership, operating constraints, and product behavior are visible in the same picture.

  3. 03 / Align

    I build for the people around the backend, too.

    Point of view
    A service boundary should make sense to the product, frontend, and operations contexts that depend on it.
    In practice
    I use explicit API contracts, shared language, and direct conversations to make integration a shared problem rather than a handoff.
    Where it shows up
    Explore selected backend work — The strongest systems make their behavior understandable across technical and product-facing roles.

    The strongest systems make their behavior understandable across technical and product-facing roles.

  4. 04 / Make it real

    I care about what happens after the feature works locally.

    Point of view
    A service needs a clear path to being run, observed, recovered, and maintained—not only a successful local demo.
    In practice
    I consider packaging, on-premise constraints, performance pressure, and observable runtime behavior alongside the service itself.
    Where it shows up
    View deployment-ready work — The goal is a system that remains understandable and dependable after it leaves the laptop.

    The goal is a system that remains understandable and dependable after it leaves the laptop.

What I work with

Backend systems

Go services, REST APIs, gRPC contracts, and microservice boundaries with explicit ownership.

AI & real-time workflows

Inference integration, recognition-related events, live data pipelines, and WebSocket delivery.

Deployment & reliability

Docker, Docker Compose, on-premise setup, resource-aware design, and runtime investigation.

Product & transactional workflows

API design, clear state transitions, frontend integration, and shared language across product teams.

Education

B.Sc. in Computer Engineering. It gave me a systems-oriented foundation that I bring into practical backend work, especially software that has to support real product operations reliably.