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.
Most engineers don’t “learn” advanced database features. They run into them after their system starts misbehaving. This is not a MongoDB tutorial.This is an honest account of how MongoDB collection.watch() (Change Streams) saved my NexoralDNS project...
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
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 value.
And like most engineers, my first instinct was wrong.
When logs start piling up, the usual suggestions appear:
“Run a cron job every night”
“Delete old data weekly”
“Let DevOps handle it”
“We’ll fix it later”
I’ve done this before.
And every time, it ends the same way:
Cron fails silently
Cleanup lags
DB size explodes
Someone gets paged
This time, I refused to repeat that mistake.
For NexoralDNS:
Analytics dashboards show last 24 hours
Free users don’t need data older than 7 days
Logs are not archival data
Accuracy matters more than history
So why was I even keeping old data?
That’s when I revisited something MongoDB already provides.
MongoDB supports TTL (Time-To-Live) indexes.
One line. No cron. No scheduler.
await DnsAnalyticsCol.createIndex(
{ createdAt: 1 },
{ expireAfterSeconds: 60 * 60 * 24 * 7 }
)
That’s it.
MongoDB automatically deletes documents:
Based on a Date field
After the specified time
In the background
Without application involvement
This is not a workaround.
This is a first-class database feature.
No cron jobs.
No Kubernetes jobs.
No external schedulers.
The database enforces retention by design.
Logs stop growing unbounded.
Disk usage becomes predictable.
Costs stay under control.
This matters more than people admit.
Cron jobs fail.
Scripts crash.
Deployments break schedules.
TTL indexes don’t care about your deployment pipeline.
They just work.
TTL indexes are simple — but not magic.
Things you must know (or you’ll get burned):
MongoDB’s TTL monitor runs roughly every 60 seconds.
If you expect millisecond-accurate deletion, you’re misunderstanding the feature.
createdAt MUST Be a DateThis will not work:
createdAt: 1710000000000 // ❌ timestamp number
This will work:
createdAt: new Date() // ✅
I’ve seen production systems silently fail because of this.
No compound TTL indexes.
No shortcuts.
Design accordingly.
Cron-based cleanup:
Runs late
Can fail
Needs monitoring
Adds complexity
TTL indexes:
Are declarative
Are enforced at the DB level
Survive redeployments
Reduce mental overhead
If your data has an expiration date, the database should own it.
In NexoralDNS:
MongoDB is the source of truth
TTL enforces retention
Change Streams handle reactivity
The application stays stateless
Each layer does one job, cleanly.
That’s how systems stay maintainable.
If you are writing cleanup scripts for data that:
Is time-bound
Has no long-term value
Is high volume
You are probably solving the wrong problem.
MongoDB already solved it for you.
Cron jobs are not architecture.
Cleanup scripts are not scalability.
And “we’ll delete it later” is technical debt.
TTL indexes are boring — and that’s exactly why they’re powerful.
Let the database do what it’s good at.
Save your engineering effort for problems that actually matter.