India · Remote-friendly
Backend Engineer transitioning to Full Stack Engineer
I build multi-tenant enterprise SaaS on Java and Spring Boot — event-driven microservices, tenant-safe search over millions of records, and APIs that hold up in production. Now extending that depth across the stack with React and TypeScript, because the best systems are designed end to end.
Three kinds of systems, one throughline: software that solves a business problem and stays maintainable after I move on.
Multi-tenant SaaS platforms with strict data isolation, auditability, and configurable workflows. Systems that replace spreadsheets and become the source of truth for a business.
REST APIs designed for correctness first: clear domain boundaries, tenant-scoped queries, caching where it earns its keep, and p95 latencies that survive real load.
Libraries and reference implementations that remove whole classes of bugs — query DSLs that are safe by construction, starters that make tenancy a configuration concern.
Case studies, not screenshots — the problem, the architecture, the trade-offs, and what happened in production.
Enterprise SaaSProduction
Enterprise equipment lifecycle platform
Multi-tenant SaaS that runs the full equipment lifecycle — installation, warranty, service, claims, inventory, and field operations — for enterprise customers.
Developer ToolsMaintained
Composable query DSL and parser for Spring Data + Elasticsearch
An open-source library that turns a compact query language into safe, parameterized, tenant-scoped queries — pluggable across SQL and Elasticsearch backends.
Long-form writing on backend architecture, distributed systems, and AI-assisted engineering.
AI Engineering3 min read
A year of using AI agents on production backend code: where they genuinely compress work, where they quietly create debt, and the review discipline that makes the difference.
Architecture3 min read
How we replaced unindexed SQL filtering with a custom query DSL compiled to tenant-scoped Elasticsearch queries — the grammar, the AST, the trade-offs, and what I'd do differently.
Distributed Systems3 min read
Dual-writes between your database and Kafka will lose events — quietly, rarely, and at the worst time. Here's the outbox pattern as actually implemented, including the parts the diagrams skip.
Short-form engineering notes — one idea at a time.
Distributed Systems1 min read
If a service writes to its database and then publishes to Kafka, there is a crash window where the commit succeeds and the event never leaves the building. It happens rarely — maybe once a month — which is exactly why nobody notices until the data has drifted. The fix costs one table. Write the event to an outbox row in the same transaction as the business change, let a relay publish it, and make consumers idempotent. Atomicity becomes the database's problem, and databases are very good at that problem.
Open on LinkedInArchitecture1 min read
Code review heuristic that has caught real incidents: search the codebase for tenant fallbacks. Every `getTenantOrDefault()` is a future cross-tenant leak wearing a convenience costume. A request that reaches the data layer without a resolved tenant should throw — loudly, immediately, in staging. Fail closed. The exception you see today is the data leak you don't see next quarter.
Open on LinkedInAI Engineering1 min read
Brilliant: stop reviewing syntax, it's clean. Never seen production: check every transaction boundary, every retry, every assumption about ordering and time. AI code fails exactly where systems fail — at the boundaries — and the polish of everything around the bug is what lulls reviewers past it. The engineers getting real leverage from AI aren't the ones who prompt best. They're the ones who review best.
Open on LinkedInOpen to senior backend and full-stack roles, and always happy to compare notes on distributed systems. Email is fastest.