About
I'm Raj — a backend engineer drawn to the problems that appear when software meets money, concurrency, and scale.
Current
SDE II · Togopool
Education
MANIT Bhopal
Location
Gurugram, India
The Work
I'm a Software Development Engineer II at Togopool, a multi-tenant mobility SaaS platform.
One of my first real production problems there was a payments incident: passengers were being charged, but drivers weren't being credited. The answer was buried somewhere inside a large, interconnected codebase.
Tracing that failure — and redesigning the wallet system so the same class of problem couldn't disappear silently again — shaped the kind of engineering work I care about.
Systems where correctness is the feature.
Since then, I've worked on payment infrastructure across five providers, distributed locking for concurrent seat reservations, fraud detection for driver incentives, and routing systems that reduced third-party API costs by 75%.
I was promoted to SDE II in January 2026, and today I own features end to end: understanding the problem, designing the system, writing the code, deploying it, observing it in production, and handling what happens when reality disagrees with the design.
Because when users can lose money, seats, or trust, correctness isn't an implementation detail.
How I Think
I care a lot about system design and architecture — but I don't think good architecture comes from trying to predict everything perfectly before writing code.
You design with what you know.
You ship.
Production teaches you what you didn’t know.
And then you come back to the system.
Once the deadline is gone and the pressure to deliver has passed, I like to revisit what I built and ask:
- Could this have been simpler?
- Where are the hidden assumptions?
- What happens at 10× the traffic?
- What happens when a dependency fails?
- What would I design differently if I started again today?
That habit matters to me because what I learn to notice after shipping eventually becomes what I notice before building the next thing.
Hindsight slowly becomes instinct.
How I Build Systems
Correctness before cleverness
When users can lose money, seats, or trust, correctness is the feature — not an implementation detail to optimize later.
Failures are first-class states
Timeouts, retries, and partial success aren't edge cases to patch. They're states the system is designed to hold and recover from.
Production is part of the design
You design with what you know, ship, and let production teach you the rest. The best version of a system is the one you revisit after reality tests it.
Observe what actually happened
Request logs tell you what the server did; domain events tell you what happened to the ride. I instrument the second, and keep it from ever breaking the first.
Still Learning
I hold a B.Tech from Maulana Azad National Institute of Technology (MANIT), Bhopal.
Right now, I'm going deeper into system design, distributed systems, and software architecture — especially the trade-offs that only start becoming interesting once a system has to survive real traffic, failures, and constraints.
The Architecture Lab on this site is where I work through those ideas in public: breaking systems apart, questioning design decisions, and trying to understand not only how something works, but why it should be built that way.
I’m still learning.
Still revisiting old decisions.
Still trying to make the next system a little harder to break than the last one.
Get in touch
The best way to reach me is by email, or you can connect with me on LinkedIn.