Backend on Tachera W Sasi, Backend & Infra Engineer (Go, Self-Hosted, Observability)

I Want to Understand Computers, Not Just Use Them

Fri, 02 Oct 2026 00:00:00 +0000

—2" tags: [“tachera”, “software-engineering”, “systems-programming”]

I’ve spent a lot of time writing software.

Web applications. Mobile apps. APIs. Backends. Databases. Deployment systems. Developer tools. And lately, more and more infrastructure and very, very low-level stuff, mostly in Zig.

And honestly, I’m starting to suspect that I have a problem.

At some point, I realized something had changed.

I don’t just want to build software anymore.

I want to understand the computer underneath it.

I want to know what happens when a process starts, how memory actually gets used, why a network connection fails, what the operating system is doing, how filesystems work, what happens when a server runs out of resources, and why a distributed system behaves differently from the beautiful little diagram I drew on a whiteboard.

The diagram, of course, assumes everything works.

The real system apparently did not receive the memo.

I want to understand the machine, not just the framework sitting on top of it.

The abstraction is useful until it isn’t

Modern software development is incredibly good at hiding complexity.

That’s one of its greatest strengths.

I can create an HTTP server without thinking about TCP. I can use a database without thinking about disk pages. I can deploy an application without manually configuring a server. I can create a mobile interface without thinking about how pixels eventually reach a display.

That’s great.

Abstraction exists for a reason.

I don’t want to manually implement TCP every time I build a todo app. That sounds like a terrible Tuesday.

But there is a point where abstraction becomes a ceiling.

You can spend years knowing React, Laravel, Next.js, Docker, Kubernetes, or whatever the industry is excited about this month without understanding much about what actually happens underneath them.

And then something breaks.

A connection starts timing out.

A process consumes all the memory.

A deployment works on one machine but not another.

A filesystem fills up.

A request occasionally takes five seconds instead of fifty milliseconds.

A queue gets backed up.

Your logs say absolutely nothing useful.

You stare at the terminal.

The terminal stares back.

Suddenly the abstraction isn’t enough anymore.

You have to go one layer deeper.

And I want to be comfortable there.

I started caring about the layers underneath

This is probably why I’ve become increasingly interested in Go, Zig, Rust, Linux, networking, distributed systems, infrastructure, and developer tooling.

They force me to think differently.

When I’m building something in Go, I find myself thinking about processes, concurrency, memory, networking, files, system calls, binaries, and failure modes.

When I’m writing Zig, I have considerably fewer layers between me and the machine.

Sometimes that’s beautiful.

Sometimes it feels like the computer has finally decided to stop protecting me from my own decisions.

Either way, I’m learning.

When I’m working with Linux, I can’t pretend the operating system doesn’t exist.

When I’m building infrastructure, I have to think about what happens when something goes wrong.

And that’s exactly what I want.

I don’t want software to feel like magic.

I want to understand the magic trick.

Preferably before production catches fire.

This is also why I build things from scratch

I’ve always had a tendency to build things I probably could have just downloaded.

Sometimes that’s objectively inefficient.

If I need file storage, there are dozens of existing products.

If I need deployment infrastructure, there are already massive platforms.

If I need a programming language, there are hundreds of them.

And yet I keep building.

VintLang started because I wanted to understand what it actually means to build a programming language.

BeamDrop exists because I wanted to build a self-hosted storage system.

Ekilie exists because I wanted to understand the infrastructure behind deploying and managing software.

At this point, I should probably learn to leave perfectly good software alone.

But there is something different about building a thing yourself.

You don’t just read about the problem.

You run directly into it.

You discover why the boring decisions matter.

You discover where systems become complicated.

You discover what breaks.

You discover that your beautiful architecture diagram did not account for the disk being full.

And, most importantly, you develop an intuition that you can’t get from reading API documentation alone.

I don’t necessarily expect every project to become a massive company.

Sometimes the project itself is the education.

Sometimes you spend three days building something that already exists because you wanted to know how it works.

That’s not always good engineering.

But it’s excellent curiosity.

I don’t want to memorize more APIs

There is a strange trap in software engineering where becoming more experienced can sometimes mean becoming better at remembering abstractions.

You learn another framework.

Another library.

Another cloud service.

Another ORM.

Another deployment platform.

Another programming language.

Another JavaScript build tool whose name you will forget in approximately six months.

And suddenly your definition of progress becomes:

How many technologies do I know?

I’m becoming less interested in that question.

I’d rather ask:

How much of the system do I actually understand?

If I know five frameworks but don’t understand networking, that’s a problem.

If I know three cloud platforms but can’t explain what happens when a Linux process runs out of memory, that’s a problem.

If I can deploy a Kubernetes cluster but don’t understand why I needed one in the first place, that’s a particularly interesting problem.

Tools are useful.

Understanding is more valuable.

The deeper I go, the more interesting software becomes

The funny thing is that learning the lower layers hasn’t made higher-level development less interesting.

It has made it more interesting.

When I write an API now, I think differently about it.

When I deploy an application, I think about the machine running it.

When I write concurrent code, I think about what the runtime and operating system are actually doing.

When I design a system, I think more about failure instead of just the happy path.

The layers aren’t separate.

They’re connected.

A web request eventually becomes bytes.

Those bytes travel through networks.

Processes consume resources.

Data ends up somewhere on storage.

The operating system manages all of it.

And underneath all of that is hardware executing instructions.

Which is slightly insane when you think about it.

You can write:

fetch("/users")

and somehow that eventually involves electricity moving around inside a machine, packets travelling through networks, operating systems scheduling work, and hardware executing instructions.

And I used to think the interesting part was the React component.

The React component is still pretty cool, though.

I’m not trying to become a “10x engineer”

I’ve never been particularly interested in that idea.

I don’t want to optimize myself into a machine that produces pull requests.

I want to become the kind of engineer who can sit in front of an unfamiliar system and eventually figure it out.

Give me a strange codebase.

Give me a broken server.

Give me an unfamiliar protocol.

Give me a performance problem.

Give me a system with terrible documentation.

I want my first reaction to be curiosity instead of panic.

Although some panic is probably acceptable.

That’s the skill I’m actually chasing.

Not knowing everything.

Knowing how to find out.

Maybe that’s what engineering really is

The older I get as a developer, the less impressive syntax feels.

Writing code is important, but code is only one part of the job.

The interesting part is understanding why the system behaves the way it does.

Understanding constraints.

Understanding trade-offs.

Understanding failure.

Understanding the environment your software lives in.

And understanding enough of the underlying machine that you aren’t completely helpless when an abstraction breaks.

That’s where I want to go.

I still love building web applications.

I still enjoy React.

I still write APIs.

I still use frameworks.

I’m not abandoning abstraction.

I’m just becoming more interested in what exists underneath it.

Because eventually, I don’t want to just be someone who knows how to use computers.

I want to be someone who understands them.

Even if that means occasionally spending six hours debugging something that turns out to be a typo.

And I think that’s a much more interesting journey.

Originally published on Medium.

Why io.Copy Is One of Go's Most Powerful Functions

Mon, 04 May 2026 00:00:00 +0000

—2" tags: [“design-pattern-in-golang”, “io”]

Most Go developers use io.Copy() early in their journey.

Usually for:

copying files
downloading HTTP responses
writing buffers

But many never realize this tiny function is sitting at the center of:

proxies
reverse proxies
SSH tunnels
database gateways
streaming systems
TCP forwarders
container runtimes
load balancers

This line:



io.Copy(dst, src)

is deceptively powerful.

Especially when you realize:in Go, sockets are just streams.

And streams are just:

io.Reader
io.Writer

Once that clicks, networking becomes MUCH simpler.

The Beautiful Simplicity

Consider this tiny PostgreSQL TCP proxy:



package main

import (
 "io"
 "log"
 "net"
)
const (
 LISTEN_ADDR = ":5433"
 PG_ADDR = "localhost:5432"
)
func main() {
 ln, err := net.Listen("tcp", LISTEN_ADDR)
 if err != nil {
 log.Fatal(err)
 }
 for {
 client, err := ln.Accept()
 if err != nil {
 continue
 }
 go handle(client)
 }
}
func handle(client net.Conn) {
 defer client.Close()
 server, err := net.Dial("tcp", PG_ADDR)
 if err != nil {
 return
 }
 defer server.Close()
 go io.Copy(server, client)
 io.Copy(client, server)
}

That’s it.

No packet parsing.
No protocol handling.
No PostgreSQL driver.

Yet this already works as a real TCP proxy.

Why?

Because TCP connections in Go implement:

io.Reader
io.Writer

Which means:

you can read from them
write to them
stream data between them

Understanding the Core Idea

This line:



io.Copy(server, client)

means:continuously read bytes from client and write them into server And this line:



io.Copy(client, server)

means:continuously read bytes from server and write them into client Together they create:

bidirectional communication
full duplex streaming

Full Duplex Communication

Most network protocols are two-way conversations.

The client sends data.
The server responds.
Both sides can speak independently.

Your browser and a web server.
SSH client and SSH server.
PostgreSQL client and PostgreSQL server.

All of them rely on duplex communication.

Visually:



client <=========> proxy <=========> server

Your proxy becomes a pipe.

And io.Copy() is what keeps bytes flowing through that pipe.

Why Goroutines Matter Here

This part is critical:



go io.Copy(server, client)
io.Copy(client, server)

Without the goroutine, communication would block.

You need:

one stream for client -> server
another stream for server -> client

simultaneously.

That’s what enables real-time two-way communication.

The goroutine handles one direction.
The main goroutine handles the other.

Tiny code.
Massive capability.

Sockets Are Just Streams

This is one of the most important concepts in systems programming.

In Go:



type Conn interface {
 Read(b []byte) (n int, err error)
 Write(b []byte) (n int, err error)
}

A socket behaves like:

a file
a buffer
stdin/stdout
an HTTP body

Everything becomes composable through interfaces.

This is why Go networking feels elegant.

You stop thinking:“I’m working with TCP packets” and start thinking:“I’m moving streams between readers and writers” That abstraction is incredibly powerful.

Memory Efficiency

Another reason io.Copy() is excellent:
it streams data incrementally.

It does NOT:

load everything into memory
allocate giant buffers
wait for full payloads

Internally, it uses reusable buffers and streams chunks continuously.

This makes it ideal for:

large files
long-lived connections
proxies
streaming systems

Even multi-GB transfers remain memory efficient.

This Pattern Exists Everywhere

Once you notice it, you’ll see this pattern everywhere.

Reverse Proxies

Forward HTTP traffic between clients and servers.

SSH Tunnels

Forward encrypted streams between hosts.

Database Proxies

Like PgBouncer or custom DB gateways.

VPNs

Moving packets through encrypted streams.

Load Balancers

Forwarding connections across machines.

Container Systems

Streaming logs, exec sessions, and IPC.

A huge amount of infrastructure software is basically:carefully managed stream forwarding.

The Hidden Superpower of Go

Go’s standard library encourages composition over complexity.

Instead of giant networking frameworks:

readers
writers
interfaces
goroutines

become enough to build real infrastructure.

This is why Go became dominant in:

cloud infrastructure
Kubernetes tooling
networking software
distributed systems

The primitives are small.
But they scale extremely far.

Final Thoughts

io.Copy() looks boring at first.

But behind that tiny function is a core systems programming idea:move streams between abstractions efficiently Once you deeply understand that:

proxies make sense
tunnels make sense
reverse proxies make sense
networking becomes less magical

And you start realizing:
some of the most powerful infrastructure on the internet is built from surprisingly small primitives.

Originally published on Medium.

After Using 10+ Languages, Go Is Still My Favorite for Backend Systems

Mon, 09 Mar 2026 00:00:00 +0000

—2" tags: [“programming-languages”, “golang”, “backend-development”, “scalable-applications”]

Golang Fanatic Here

Introduction

Over the past few years I’ve experimented with a lot of programming languages.

PHP, JavaScript, TypeScript, Python, Java, Go, Rust, C, C++, and several others. I enjoy exploring languages because every language teaches you something about how software should be built.

Some languages are great for rapid prototyping.
Some shine in performance-critical environments.
Others dominate specific ecosystems.

But when it comes to building backend systems , I keep coming back to Go.

Not because it’s the most advanced language.
Not because it has the most features.

Actually, the opposite.

Go wins because it focuses on simplicity, performance, and practical tooling.

1. Simplicity

One of Go’s biggest strengths is that the language is intentionally small.

There are no complex generics systems like in C++.
No endless abstractions like in some object-oriented languages.
No massive meta-programming layers.

At first this feels limiting.

But after building real systems, you realize something important: most backend problems don’t need complex language features.

They need:

• readable code
• predictable behavior
• easy maintenance

Go enforces a style that makes codebases easier to understand, especially in teams.

There’s a reason many companies adopt Go for large services: engineers can read each other’s code easily.

2. Concurrency That Actually Feels Simple

Modern backend systems are inherently concurrent.

You’re dealing with:

• multiple HTTP requests
• database operations
• background jobs
• external services
• queues and event streams

In many languages, concurrency means dealing with complex thread models, locks, or async frameworks.

Go solves this elegantly with goroutines and channels.

Starting a concurrent task is as simple as:



go processRequest()

That single keyword launches a lightweight concurrent task.

Behind the scenes Go handles scheduling, making it incredibly efficient.

This model makes it easy to build systems like:

• API servers
• job processors
• streaming services
• high-throughput workers

without drowning in concurrency complexity.

3. Fast Compilation Changes Your Workflow

This is something many developers underestimate.

Go compiles extremely fast.

That means your development loop becomes:

edit → build → run → repeat

And the build step takes seconds.

Compare that to some compiled languages where builds can take minutes on larger projects.

Fast compilation encourages experimentation and rapid iteration.

It also makes Go great for:

• CLI tools
• microservices
• infrastructure tooling

4. Tooling That Just Works

One thing Go gets very right is its tooling philosophy.

Many languages rely heavily on external tools and third-party plugins.

Go ships with most of what you need built in:

• gofmt for automatic code formatting
• go test for testing
• go build for compiling
• go mod for dependency management
• profiling and benchmarking tools

Because these tools are standardized, Go projects tend to look and behave consistently.

You spend less time configuring tools and more time building software.

5. Why Go Is Excellent for APIs

Go has become one of the most popular languages for building APIs, and for good reason.

It hits the sweet spot between performance and simplicity.

The standard library alone gives you a powerful HTTP server:



http.HandleFunc("/api", handler)
http.ListenAndServe(":8080", nil)

No heavy frameworks required.

This makes Go ideal for:

• REST APIs
• microservices
• internal tooling services
• high-performance backends

It’s also incredibly easy to deploy because Go compiles to a single static binary.

No runtime dependencies.
No complicated deployments.

Just ship the binary and run it.

Final Thoughts

Go isn’t perfect.

It’s not the most expressive language.
It’s not the best choice for everything.
And sometimes it feels intentionally minimal.

But for backend systems, that minimalism becomes a strength.

You get:

• simple code
• strong performance
• built-in tooling
• great concurrency

After using more than 10 programming languages, Go remains the language I trust the most when building backend systems.

Not because it’s flashy.

Because it gets the job done reliably.

Originally published on Medium.

Why Most Engineers Shouldn't Build Distributed Systems (And Why I Did Anyway)

Thu, 05 Mar 2026 00:00:00 +0000

—2"

Distributed systems are one of the most fascinating areas in software engineering.

They’re also one of the fastest ways to accidentally create massive complexity.

A lot of engineers jump straight into microservices, container orchestration, and distributed architectures because it sounds scalable and modern.

But in reality, distributed systems introduce an entirely new category of problems.

When your system runs on a single machine, many things are simple.

Function calls are instant.
Memory access is predictable.
Failures are easier to understand.

For example, a local function call might look like this:



func processOrder(orderID string) error {
 order := getOrder(orderID)
 chargeCustomer(order)
 updateInventory(order)
 return nil
}

Everything happens inside one process.
No network. No timeouts. No partial failures.

But once your system becomes distributed, the same operation might involve multiple services communicating over the network.



func processOrder(orderID string) error {
 order, err := orderService.Get(orderID)
 if err != nil {
 return err
 }


 err = paymentService.Charge(order.CustomerID, order.Total)
 if err != nil {
 return err
 }


 err = inventoryService.Reserve(order.Items)
 if err != nil {
 return err
 }


 return nil
}

Now things become much more complicated.

What happens if the payment service succeeds but the inventory service fails?

What if the network times out but the request actually succeeded?

What if the service crashes halfway through the workflow?

These are common distributed system problems.

Failures Become Normal

In distributed systems, failures are not exceptions.

They are expected behavior.

A simple HTTP call can fail in many ways:



resp, err := http.Get("http://node-service/tasks")


if err != nil {
 // network failure 
 retry()
}

But what kind of failure is it?

The server might be down
The network might be slow
DNS might fail
The request might succeed but the response gets lost

Handling these cases correctly requires retries, timeouts, and idempotent operations.

Scheduling Work Across Machines

One of the challenges I encountered while building a cloud orchestration system was scheduling workloads across multiple nodes.

A very simplified scheduler might look like this:



type Node struct {
 ID string
 Capacity int
 Used int
}


func schedule(nodes []Node, job Job) *Node {
 for i := range nodes {
 if nodes[i].Capacity-nodes[i].Used >= job.Resources {
 return &nodes[i]
 }
 }
 return nil
}

This looks simple.

But real systems quickly introduce more challenges:

nodes going offline
jobs failing midway
resource fragmentation
network delays
distributed state

A production system requires heartbeat monitoring, leader election, failure recovery, and task rescheduling.

Suddenly the architecture grows significantly.

Debugging Becomes Harder

Debugging distributed systems is also more complex.

In a monolith, you can follow logs sequentially.

In a distributed system, a single request might pass through several services:



API Gateway -> Auth Service -> Order Service -> Payment Service -> Inventory Service

To debug issues, you often need distributed tracing tools to reconstruct the path of a request.

Without observability, diagnosing issues becomes extremely difficult.

Do Most Companies Need This?

In many cases, the answer is no.

A well designed monolith can scale surprisingly far.

Many successful products run on monolithic architectures much longer than engineers expect.

Distributed systems should only be introduced when they solve a clear scaling or reliability problem.

But There Is Still Value in Learning Them

Even though most systems don’t need distributed architectures immediately, understanding them provides enormous value.

Once you understand how systems fail across networks and machines, you begin designing software differently.

You think more about:

fault tolerance
system boundaries
reliability
observability

Those lessons improve every backend system you build.

Distributed systems are powerful tools.

But like all powerful tools, they should be used carefully.

Originally published on Medium.

Escape Analysis in Go: Where Does Your Data Actually Live?

Fri, 20 Feb 2026 00:00:00 +0000

—2"

If you’ve been writing Go for a while, you’ve probably heard the terms stack and heap tossed around. But have you ever wondered how Go decides where to put your variables? That’s exactly what escape analysis is about and understanding it can help you write faster, more efficient Go code.

Stack vs Heap: A Quick Refresher

Think of memory in two buckets:

Stack Fast, automatically managed. When a function is called, variables are pushed onto the stack. When the function returns, they’re gone. No cleanup needed.
Heap Slower, but longer-lived. Variables here are managed by Go’s garbage collector (GC). They stick around as long as something is referencing them.

The stack is cheap. The heap costs more allocating on the heap puts pressure on the GC, which can slow your program down.

So What Is Escape Analysis?

Escape analysis is what the Go compiler does at compile time to figure out: “Does this variable need to live on the heap, or can it stay on the stack?”

If a variable is only used inside the function it was created in, it can safely live on the stack. But if a variable “escapes” meaning something outside the function needs to access it it has to be moved to the heap.

The compiler does this automatically. You don’t have to think about it most of the time. But understanding when things escape can help you avoid unnecessary heap allocations.

A Simple Example



func main() {
 x := 42
 fmt.Println(x)
}

Here, x is created and used inside main. It doesn’t escape anywhere. The compiler keeps it on the stack.

Now consider this:



func newNumber() *int {
 x := 42
 return &x // we're returning a pointer to x 
}

Here, we’re returning a pointer to x. That means after newNumber returns, something outside the function is still holding a reference to x. The stack for newNumber is gone at that point so Go moves x to the heap. It has escaped.

How to See What’s Escaping

Go gives you a handy compiler flag to inspect escape analysis decisions:

bash



go build -gcflags="-m" ./...

You’ll see output like:



./main.go:6:2: moved to heap: x
./main.go:10:13: ... argument does not escape

This tells you exactly which variables the compiler decided to allocate on the heap. It’s a great debugging tool when you’re trying to optimize performance.

Common Reasons a Variable Escapes

1. Returning a pointer to a local variable As shown above if you return &x, x has to live on the heap.

2. Storing a value in an interface



var i interface{} = 42

When you assign a concrete value to an interface, Go often needs to heap-allocate it because the interface value needs to carry around type information.

3. Sending to a channel or storing in a slice/map If the runtime can’t prove the value won’t outlive the current scope, it plays it safe and puts it on the heap.

4. Closures capturing variables



func makeCounter() func() int {
 count := 0
 return func() int {
 count++
 return count
 }
}

Here, count is captured by the closure returned from makeCounter. Since the closure can be called long after makeCounter returns, count escapes to the heap.

Does This Matter in Practice?

For most applications, not really Go’s garbage collector is fast and well-tuned. But in performance-sensitive code (think: game loops, high-frequency trading, large-scale data pipelines), reducing heap allocations can make a meaningful difference.

Here’s a rough guide:

Don’t return pointers to small, short-lived values if you don’t need to. Return by value instead.
Pre-allocate slices when you know the size upfront (make([]int, 0, 100)) to avoid repeated heap allocations.
Use**-gcflags= “-m” or benchmarks** to identify hot paths with lots of allocations before optimizing.

Key Takeaways

Go automatically decides whether variables live on the stack (fast, temporary) or the heap (slower, GC-managed).
This decision is made by the compiler using escape analysis.
A variable “escapes” to the heap when it needs to outlive the function it was created in.
You can inspect escape decisions with go build -gcflags="-m".
Understanding escape analysis helps you write more allocation-efficient Go code.

The beauty of Go is that you don’t have to think about this most of the time. But when performance matters, escape analysis is one of those things that separates good Go code from great Go code. Happy coding! 🚀

Originally published on Medium.