Bio

I work on backend systems and infrastructure, usually in places where things break in non-obvious ways and logs start lying to you. If something works but no one understands why, it makes me uncomfortable.

A significant part of my time has been spent designing and maintaining message-driven systems: middleware, service-to-service communication, and backend architectures where components talk over queues, sockets, and protocols rather than assumptions.

I’ve worked with distributed systems where latency, backpressure, and failure modes matter more than clean diagrams, and where “it works on my machine” is not considered a valid debugging strategy.

I tend to gravitate toward systems that stay up for a long time, accumulate history, and eventually expose every bad decision ever made. This includes Linux servers, container platforms, networking setups, and backend services that refuse to fail politely.

I prefer tools and architectures that are explicit, observable, and boring in the best possible way. If a system requires magic to operate, I will probably try to remove it.

This site exists as a place to write things down before I forget why something was built the way it was.