Hi, I'm
A software engineer building distributed systems, cloud infrastructure platforms, and fault-tolerant runtime layers — most interested in what happens when systems get loud.
Each project is a full case study — the problem, the architecture, and the decisions that made it hold. Shipped work and system-design concepts, clearly marked.
A control plane built so the decision layer scales horizontally and stays fast — orchestrating millions of transactions across distributed compute without becoming the bottleneck.
Failover that doesn't wait for a human
One standard way to run a workload
500K+ events a second, nothing lost
From “something's wrong” to root cause
Environments you can rebuild from a commit
Break it on purpose, before production does
Isolation and audit trails built into the platform
How I'd approach classic problems — designs and explorations, not shipped products. Marked as concepts so nothing here pretends to be more than it is.
From raw events to live dashboards
One front door for many services
Find the one line that explains the outage
Architect and operate distributed compute and infrastructure platforms for enterprise-scale workloads. The work spans a Java 21 control plane orchestrating 8M+ daily transactions at sub-18ms p95, Go and Kubernetes automation that keeps 40+ production microservices at 99.98% uptime, a Linux-based container runtime platform across 500+ service instances, and the Kafka, observability, IaC, and security layers that make it all reliable — alongside SRE and platform teams in Agile sprints.
Enterprise-scale transaction volume needed a compute platform that could scale horizontally without the orchestration layer becoming the bottleneck.
Architected a horizontally scalable Java 21 distributed compute platform with a control plane and distributed state management, handling 8M+ daily transactions at sub-18ms p95.
Failures in production microservices depended on people noticing and responding, stretching outages and risking cascades.
Engineered a self-healing automation layer in Go on Kubernetes — automatic failover, replication, and recovery-oriented restart policies — delivering 99.98% uptime across 40+ microservices.
Provisioning and running workloads varied by team, slowing delivery and making operations inconsistent across hundreds of services.
Built a Linux-based container runtime management platform on Docker and Kubernetes schedulers, standardizing orchestration across 500+ containerized instances and cutting provisioning time by 63%.
Event data had to move at very high volume across regions without loss, and incidents had to be understood and repaired quickly.
Developed a fault-tolerant Kafka pipeline (500K+ events/sec, 99.97% delivery, zero data loss guarantees) and an OpenTelemetry + Datadog APM observability stack that cut MTTR by 51%.
Fairfax, VA
Small, honest demos of the patterns behind the work — a token-bucket limiter, exponential backoff, a cache — running right here in your browser. Plus the deeper case studies they come from.
Most software works on the happy path. I spend my time on the other one — the 3 a.m. spike, the retry storm, the dependency having a bad day. The systems I'm proud of aren't the ones that never fail; they're the ones that fail in ways you can see, contain, and recover from.
That turns into a way of working. I start from the failure and design backward, so the good day takes care of itself. I'd rather ship something simple and correct than clever and occasionally wrong. And I try to leave every system more legible than I found it — explicit states, honest names, runbooks that actually get used — so the next engineer, or the next on-call, can move without fear.
Start at what breaks under load, then work back to the architecture. The happy path takes care of itself.