Search for a command to run...
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.
No comments yet. Be the first to comment.
I document what I learn, build, and reflect on during weekends and free time. This is a progress log, not tutorials—just honest notes on engineering, mistakes, and growth as a software engineer.
Building an AI agent that deploys Cloudflare Workers with LangChain.js, and the Redis circuit breaker that keeps it running after the free tier dies.
Building an AI agent that deploys Cloudflare Workers with LangChain.js, and the Redis circuit breaker that keeps it running after the free tier dies.
How AxioDBCloud went from an open TCP socket to a TLS-encrypted, authenticated, pooled, and AI-drivable system in seven days. There is a specific kind of discomfort that comes from looking at your ow
Most Node.js tutorials stop at "it works on my machine." Production is where the interesting failures live, and they rarely show up in your logs. Memory climbs for no visible reason. One endpoint pegs
Recently, I got invited to mentor at HackArena 2.0 - Kolkata Zonals, held at Jadavpur University. Honestly, when the invite landed in my inbox from the Ignite Room team, I wasn't sure what to expect.
The pricing problem that would not leave me alone I have been working with Cloudflare Workers for a long time now. I have contributed to a few open source tools in the Workers ecosystem, deployed Work
AnkanHub
20 posts
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.
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.
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.
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.
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.
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.
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.
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.
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.
Continue Go with real-world use cases
Push AxioDB performance improvements further
Harden NexoralDNS policies and edge cases
One weekend at a time.
