Building Beyond the Tutorial

I've reached a point where building another UI or wiring up a few API routes isn't enough. I want to understand what happens when real systems fail, traffic increases, jobs get retried, and deployments go wrong.

I'm a B.Tech Information Technology student at North Eastern Hill University, and most of my learning comes from building, deploying, debugging, and then going back to understand what I could have done better.

From Features to Systems

Working on Relay, my real-time messaging project, pushed me beyond writing endpoints. I had to deal with WebSocket connections, database persistence, Docker, Nginx, AWS EC2, and a CI/CD pipeline that could deploy changes to a running application.

Deploying something is a different experience from running it locally. Configuration, networking, process health, logs, and resource limits suddenly matter just as much as the code.

Learning in Public

I'm now spending more time on backend and infrastructure concepts: caching, request coalescing, queues, retries, idempotency, observability, and failure handling. The goal is not to collect buzzwords. It's to implement these ideas, test their trade-offs, and explain what I learn.

I'm also contributing to existing codebases. My merged fixes in Kestra taught me to trace behavior through unfamiliar code, understand the surrounding implementation, and keep changes focused.

What Comes Next

I'm building Slivx, a TypeScript webhook infrastructure project, to explore delivery attempts, retries, leases, and failure recovery in a system where work cannot simply disappear.

I'll use this space to share implementation notes, architecture decisions, bugs, benchmarks, and lessons from the process—not pretend every project is already operating at massive scale.

If you're interested in backend engineering, infrastructure, or building things that survive beyond the happy path, let's compare notes.