Discovering Go and Real Systems: My 2025 Christmas Holiday Experience
System-level engineer building reliable backend systems with a focus on performance, correctness, and real-world constraints. I work across APIs, databases, networking, and infrastructure, enjoy understanding how systems behave under load and failure, and write to break down complex backend and distributed-systems concepts through practical, real-world learnings.
Holidays usually mean rest. For me, this one became a quiet reset—four days of learning, breaking things, debugging late-night bugs, and slowly moving forward.
From 25th to 28th December 2025, I decided to use my free time intentionally. No pressure to “ship fast.” Just learn deeply and build things that actually matter to me.
This is a log of what I worked on, what went wrong, and what I learned.
Starting My Go Journey (25–28 December)
On 25th December, I started a Golang learning series on YouTube. My goal wasn’t to rush through it, but to finally understand Go the right way.
Over these four days, I covered:
Go basics and syntax
Goroutines and concurrency
Mutex and race conditions
Channels and communication patterns
Go I/O
Generics (yes, finally)
Go feels simple on the surface, but once you touch concurrency, it forces you to think clearly. You can’t “hack your way through” like in some other ecosystems. That constraint is actually refreshing.
AxioDB: Optimizing File Read with Worker Threads
Parallel to learning Go, I worked on AxioDB, my side project.
The focus was file reading using worker threads and improving performance. I refactored the logic to run file reads concurrently using Promise.all, but that’s where things started breaking.
Problems I faced:
Worker thread spawn errors
Random syntax errors inside workers
Buffer-related crashes under load
Inconsistent execution order
Nothing failed consistently, which made debugging harder.
After multiple iterations, I optimized how workers were spawned and how buffers were handled. The key lesson here: concurrency bugs don’t shout—they whisper. If you don’t slow down and reason properly, you’ll miss them.
NexoralDNS: Access Control Policies (The Hard Part)
The most challenging work during these holidays was on NexoralDNS.
I implemented Access Control Policies, which allow:
Blocking specific IPs or IP groups
Restricting access to certain domains or domain groups
Admin-defined rules that apply across a LAN
This is one of the most critical features of the product—and it showed.
The Idempotency Bug That Drove Me Crazy
While building the admin panel (Next.js frontend + Fastify backend), I hit a weird issue:
Clicking “Create Policy” once sometimes created two records.
No frontend double-submit.
No backend error.
DB-level checks already existed.
Still… duplicate entries.
After deep debugging, I realized the issue wasn’t validation—it was request duplication under concurrency.
The fix
I implemented an in-flight request tracker:
Store request keys temporarily in memory
If the same request arrives again, hold it
After the first request completes, return an “already exists” response
This solved the issue cleanly and taught me something important:
Idempotency is not optional in real systems. It’s mandatory.
Rethinking Database Schema Design
I also spent time reading and revisiting database schema design, especially for MongoDB.
The focus was on:
Proper relationships between collections
Designing for faster lookups
Avoiding unnecessary joins
Making future scaling easier
Using MongoDB as the primary database means schema decisions matter—even in a “schema-less” world.
Final Thoughts
I didn’t ship a flashy feature.
I didn’t write a viral post.
But I learned deeply.
These four days reminded me why I enjoy building systems:
Debugging unclear problems
Understanding how things actually work
Slowly getting better, not louder
Progress doesn’t always look impressive from the outside—but it compounds quietly.
What’s Next
Continue Go with real-world use cases
Push AxioDB performance improvements further
Harden NexoralDNS policies and edge cases
One weekend at a time.