My Developer Journey: From Building Apps to Understanding Systems

I'm studying Information Technology at North Eastern Hill University, but I don't want my learning to stop at completing coursework or getting an application to run on my laptop. I want to understand how software is structured, deployed, debugged, and kept reliable.

The fastest way I've found to learn is to build something, hit a problem I don't fully understand, and investigate until I can explain the cause—not just copy a fix.

Building Relay

Relay is my real-time messaging application. It combines a TypeScript and Node.js backend with Socket.IO, database persistence, and a React frontend.

Getting it deployed was a different challenge from getting it to work locally. I worked with Docker, Nginx, AWS EC2, HTTPS, and GitHub Actions to build a repeatable deployment flow. I also load-tested the API to get a baseline for throughput and tail latency.

The useful lesson wasn't that one benchmark number proves a system scales. It was that performance needs to be measured under a defined workload, and that the results only mean something when the test conditions are clear.

Learning Through Open Source

Contributing to Kestra gave me a different kind of problem: working inside a codebase I didn't design. I merged fixes for stale unsaved-state indicators after restoring a Flow revision and for nonfunctional time-range filter selectors.

That work required following existing component behavior, understanding how state moved through the UI, and making a targeted change without casually rewriting surrounding code. It's a useful discipline for any engineer joining an established team.

Going Deeper on Backend Engineering

I'm now exploring the parts of backend systems that become important when things fail: retries, idempotency, queue processing, caching, request coalescing, timeouts, and observability.

My current project, Slivx, is a TypeScript webhook infrastructure engine. I'm using it to learn about reliable event delivery, attempts, leases, and recovery when a destination is slow or unavailable. I want the implementation and its failure cases to teach me more than a diagram alone could.

How I Want to Learn

I try to follow a few principles:

• Build, then measure. Test behavior and performance instead of assuming an implementation is good.
• Understand failure paths. Think about timeouts, retries, duplicate work, and partial failures—not only successful requests.
• Read real code. Open-source repositories expose design decisions and edge cases that tutorials often skip.
• Explain the trade-offs. If I choose an approach, I want to be able to say why and what it costs.

What's Next

I want to keep improving my backend and DevOps fundamentals, contribute to more real-world codebases, and build projects that demonstrate sound engineering decisions.

I'll use this blog to document the work as it happens: the architecture, the mistakes, the measurements, and what I change after learning more. The aim is to share honest engineering notes—not to claim I've solved problems I am still learning to understand.