On Building Systems That Matter

I've spent the last decade building infrastructure at scale. At ShareChat, I led the design of feed infrastructure and ML platforms serving 300+ million monthly active users. At Airbnb, I worked on embedding-based retrieval platforms and verification systems for regulatory compliance across global markets. At Times Internet, I built the content platform backbone for India's leading news publishers.

Here's what I've learned: Most infrastructure problems aren't actually infrastructure problems. They're constraint problems. You can build a theoretically perfect system given unlimited compute, but you never have unlimited anything: not time, not budget, not team coordination, not regulatory clarity.

The frameworks everyone cites: microservices, event-driven architecture, feature stores, real-time ML inferencing, they're not wrong. But they're also not the answer to the question people think they're asking. They solve specific problems under specific constraints. Use them somewhere else, and you've just added complexity without solving anything.

I spent years watching teams implement solutions because they worked at Google or Netflix, only to realize those solutions were designed for Google's or Netflix's constraints, not theirs. A feature store makes sense when you have 300M users and model retraining that takes hours. It's overengineering when you don't. Consistency matters differently at an e-commerce company than at a content platform. Latency constraints for real-time feed ranking aren't the same as latency constraints for regulatory verification.

The patterns that actually matter are the ones about thinking clearly under constraints, about understanding what you're trading off and why.

What This Site Is

This is where I think out loud about infrastructure, product decisions, and the trade-offs that don't make it into polished talks or presentation decks. I'm interested in the moments where:

• Conventional wisdom breaks down. Why does everyone build feature stores the same way when no two companies' problems are actually the same?
• Constraints force better decisions. Some of the best architecture I've seen came from engineers working within tight budgets or regulatory requirements, not those with unlimited resources.
• Scale creates new kinds of problems. The challenges of coordinating humans across engineering, AI, product, design, ops, legal, CXOs are different from the challenges of building the system itself.
• You're always choosing what to optimize for. Engagement vs. diversity. Consistency vs. availability. Speed to market vs. technical debt. Most debates are really about which trade-off you're willing to accept.

I've made my fair share of mistakes in these decisions. I've also seen patterns repeat across different companies and problem domains. This site is about sharing both.

Why Now

I recently stepped away from a large-scale engineering role to work on my own vision, something that excites me from a problem statement perspective, not just from an optimization perspective. That shift made something clear: I've spent years solving for the next problem at the current company, but rarely stepping back to ask what problem am I actually trying to solve, and why does it matter?

That question changes everything about how you think about systems' design.

The blog is partly about documenting that journey. But mostly, it's a place to write for people who are thinking about similar things: engineers building the infrastructure that other products depend on. Founders wrestling with what to optimize for when you can't optimize for everything. Teams trying to make decisions that will still make sense when everything changes.

What You'll Find Here

• Deep dives on architectural decisions I've seen work (and not work) at scale
• Honest takes on the tools and patterns everyone talks about but few write critically about
• Thinking through trade-offs in public, not declaring winners
• The constraints that mattered most in decisions that looked obvious in hindsight but weren't at the time

If you're looking for frameworks or best practices, there are better places for that. This is for people who understand that "best practice" is context-dependent, and sometimes the smartest thing you can do is acknowledge why something doesn't fit your constraints.