about

I'm Rahul, a software engineer from Jaipur, currently in Gurugram for work. I work at a salestech startup, mostly on the backend: real-time event-driven systems, the AI tooling around them (agents, RAG, an internal MCP server that exposes our platform data to LLMs), and the pipelines that score and rank accounts at scale.

A rule I keep coming back to: understand the layer beneath the one you work on. The database, the network, the runtime, the protocol. Not all of it, just enough to know where it bends, because that's the difference between debugging a system and guessing at it.

I get there two ways, and they feed each other. One is building the primitives myself: I wrote Kraken, an HTTP server in C, on top of Owl, a small data-structure library I built alongside it, and lsmtree, a storage engine in Go. Not because the world needs another HTTP server or LSM tree, but because once you've built one, the real thing stops being a black box.

The other is reading: papers, source, and the engineering write-ups where companies like Uber, Meta, and Zerodha explain how they reshaped their systems to survive their scale. I want the whole pipeline, not just the parts. Why an LSM tree beats a B-tree on writes and loses on reads. Why Raft picked understandability over Paxos's flexibility. Why Postgres keeps replication and sharding as separate problems while CockroachDB folds them into one. Why Vitess had to exist at all.

Connecting those two, first principles underneath and real production systems on top, is the part I actually care about. It's what lets you look at a problem and reach for the tool that fits its read/write pattern and its scale, instead of the one you already know.