Designing scalable distributed systems & AI infrastructure.

About

Software engineering, at the systems level.

I'm a software engineer who ended up specializing in distributed systems mostly by chasing the same question across every project I've built: what actually breaks when this has to serve a thousand people at once instead of one? That question is why I care more about what happens at the queue, the cache, and the database index than about the framework of the week.

Most of my recent work sits at the intersection of backend architecture and AI infrastructure — building RAG pipelines that don't fall over under document ingestion load, multi-tenant systems where one noisy customer can't degrade everyone else's latency, and real-time platforms where the hard part isn't sending a message, it's agreeing on where every socket lives right now. I like this kind of problem because the constraints are unforgiving and the tradeoffs are concrete — consistency versus latency, throughput versus cost, simplicity versus flexibility — and getting them right is the actual craft.

I also spend a lot of time on the un-glamorous half of engineering: performance. Cutting an AI chatbot's reply time from five seconds to under two, or a Lighthouse score from 62 to 84, isn't a rewrite — it's profiling, finding the two or three things actually responsible, and fixing exactly those. That discipline of measuring before optimizing is probably the single habit that's saved me the most time in production.

Outside of the resume line items, I'm just someone who enjoys system design as a craft in its own right — sketching an architecture on a whiteboard before writing a line of code, and being a little too willing to explain why a particular caching strategy is the interesting part of a project.