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.
Every backend system that deals with logs eventually hits the same problem: Data keeps growing, storage keeps increasing, and nobody wants to own cleanup. In my case, it was DNS analytics logs in NexoralDNS. High-volume.Write-heavy.Low long-term va...
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
Today, I was working on an admin panel feature.
Simple task.
One button.
One API.
👉 “Create Policy”
I clicked the button.
Policy created âś…
Clicked again (by mistake)…
Another policy created ❌
Clicked again (slow network)…
Boom — three duplicate records.
No error.
No crash.
Just silent damage.
That day, I didn’t just fix a bug.
I learned why idempotency exists — and why every backend engineer must understand it.
Let me explain idempotency in the simplest, most practical way possible.
An operation is idempotent if doing it once or doing it 10 times gives the same final result.
That’s it.
No jargon.
No theory.
Pressing an elevator button multiple times → elevator still comes once
Turning a light ON multiple times → light stays ON
Setting your name to "Ankan" again and again → name doesn’t change
That’s idempotent behavior.
In my case:
User clicked Create Policy
Network was slow
User clicked again
Frontend sent multiple requests
Backend happily created multiple policies
From the backend’s point of view:
“I received requests, so I executed them.”
From the product’s point of view:
“Why the hell do I have duplicate data?”
This is where idempotency saves you from yourself.
POST /create-policy
Every request = new record
Click twice = two records
PUT /policy/{policyId}
Same request, same ID = same result
No duplicates.
| Method | Idempotent? | Why |
| GET | âś… Yes | Just reads data |
| PUT | âś… Yes | Replaces resource |
| DELETE | âś… Yes | Deleting again does nothing |
| POST | ❌ No | Creates new resource |
POST is dangerous if you don’t handle idempotency manually.
Even if:
Your UI is perfect
Your users are careful
Still, duplicates happen because of:
Slow internet
Mobile retries
Load balancers
User impatience
Browser refresh
Backend must be defensive. Always.
Frontend sends a unique key:
X-Idempotency-Key: abc123
Backend logic:
If key already exists → return old response
If not → process and store key
Same request = same result.
For example:
Policy name
Policy + domain combination
If duplicate comes → DB blocks it.
This is real protection, not just code-level hope.
Yes, frontend disabling helps.
But frontend is not security.
Backend must assume:
“User can do anything.”
Idempotency is not about syntax.
It’s about thinking in failure scenarios.
Senior engineers ask:
What if request retries?
What if client crashes?
What if load balancer repeats request?
What if user double clicks?
Junior engineers assume:
“It won’t happen.”
Reality says:
“It WILL happen.”
Payment APIs
Order creation
Policy creation
Signup / onboarding
Webhooks
Cron jobs
Distributed systems
Anywhere money or data integrity is involved.
If repeating an operation can break your system,
your system is fragile.
Idempotency makes systems boring, predictable, and safe —
and boring systems scale the best.
Idempotency is not optional.
It’s not “extra”.
It’s not “later”.
If you’re building APIs and not thinking about idempotency,
you’re one retry away from a production bug.
I learned this the hard way.
You don’t have to.