Yasin Engin · Go Systems

Backend systems are where network behavior becomes software behavior.

I use Go projects to make control boundaries concrete: who owns state, how services communicate, what survives a failure, and which evidence tells an operator what actually happened.

Why this belongs beside network engineering

Modern network operations depend on inventories, controllers, APIs, workers, event streams, databases, and observability systems. Learning how those components fail is part of learning how programmable infrastructure fails. Go gives me a compact way to explore concurrency, explicit error handling, protocol boundaries, and deployable services without hiding the transport layer.

The projects in this track are not one product split into arbitrary repositories. Each isolates a different systems question: source-of-truth design, replicated state, event-driven service boundaries, or protocol-level networking.

Four systems questions

1. Where does truth live?The network inventory API models locations, devices, interfaces, VLANs, users, audit logs, and operational data in PostgreSQL.
2. What survives a node failure?Tolerex explores leader-based replication, disk persistence, heartbeat detection, secure gRPC, and crash-aware reads.
3. How should services communicate?Netreka Nexus separates synchronous gRPC and REST paths from asynchronous RabbitMQ delivery and manual ACK/NACK behavior.
4. What does the protocol really do?Go Network Programming reduces the stack to TCP, UDP, HTTP, DNS, ICMP, CIDR, timeouts, and concurrent socket behavior.

Project evidence

• Enterprise Network Inventory API
  Go, PostgreSQL, JWT, RBAC, validation, pagination, audit logs, and Docker.
• Tolerex
  Leader replication, mTLS gRPC, heartbeat detection, persistence, and observability.
• Netreka Nexus
  RabbitMQ, gRPC logging, Docker Swarm, Caddy, PostgreSQL, and MongoDB.
• Go Network Programming
  Protocol experiments with sockets, timeouts, concurrency, and diagnostics.

The architecture habits I am practicing

• Make ownership boundaries visible in APIs, schemas, and service responsibilities.
• Choose synchronous or asynchronous communication according to failure and delivery semantics.
• Carry deadlines, cancellation, authentication, and error meaning across service calls.
• Separate durable state from derived or operational state.
• Design logs and metrics around questions an operator will ask during failure.
• Keep local deployment reproducible with containers and explicit configuration.

What the projects do not claim

Next direction

I am moving toward stronger integration between network source-of-truth data, automation workers, gRPC control surfaces, event-driven workflows, and measurable post-change validation. The research question is not simply how to add more services; it is how to keep ownership and failure understandable as the control plane grows.