What I Learned Building Scalable Backend Systems
Six lessons from building systems that process millions of events a day — most of which I had to learn the hard way.
Hi, I'm
Software Engineer — Backend & Distributed Systems
Building Distributed Data Processing Pipelines at Scale
I build scalable backend systems and distributed data processing pipelines that handle millions of events a day — with a focus on throughput, correctness, and cost.
APIs, service architectures, and the data layers behind them. I care about correctness, latency, and cost — not in that order, but all three at once.
Pipelines that move and transform data at volume, without drift, duplication, or silent failures that only show up in the dashboard.
Backend infrastructure for LLM-powered products — retrieval pipelines, API wrappers, evaluation loops, and the boring glue that makes them reliable.
I'm a software engineer with 4+ years of experience building distributed backend services, event-driven workflows, real-time streaming systems, and ML-assisted decision pipelines. My work spans the full production stack — from event propagation and state management to caching layers, streaming infrastructure, and the observability tooling that keeps it all running.
I currently work at Openlane, where I own core .NET Core services in a distributed inspection workflow platform processing 300K+ daily vehicle inspections and 3.5M+ events/day. I've designed Apache Pulsar-based event systems with replay-safe consumers, built ML-assisted decision pipelines that generate risk scores for rule engines and review queues, and led production rollouts using Terraform-managed canary deployments that reduced MTTD by 45%.
Before Openlane, I interned at Mayo Clinic as a Research Software Engineer, building multi-view CNN training pipelines in PyTorch for medical imaging — raising model accuracy from 87% to 95% and cutting false-negative rate in half. Earlier at Infosys, I built a real-time DDoS detection pipeline on Kafka and Flink that ingested 2M+ network flow records per second and cut detect-to-mitigate latency from 25s to under 8s.
I care about boring, well-instrumented systems. Observability before optimization. Idempotency before clever retry logic. The systems I'm proudest of are the ones that don't page anyone at 3 a.m.
Selected work from production systems — the engineering decisions, tradeoffs, and outcomes.
Notes from the field on backend systems, performance, and what engineering judgment actually looks like.
Six lessons from building systems that process millions of events a day — most of which I had to learn the hard way.
A step-by-step breakdown of how we traced a latency problem to its real root cause and fixed it with layered Redis caching — without touching the database.
AI tools make good engineers faster. They don't make shallow engineers deep. Here's why fundamentals matter more than ever.