I'm a software engineer focused primarily on backend development with Java.

I currently work with Java on the backend at Plumii, and I'm particularly interested in understanding software beyond the framework level — from JVM behavior and performance, through networking, to distributed systems and cloud-native architectures.

Outside of application development, I maintain a collection of engineering labs where I learn by implementing things, breaking them, measuring them, and documenting what I find.

Experiments around Java, the JVM, performance engineering, concurrency, memory, and data structures.

Topics include allocation and GC behavior, escape analysis, object layout, JIT behavior, contention, false sharing, custom data structures, I/O, and benchmarking.

The goal is not just to make code faster, but to understand why the machine behaves the way it does.

Learning computer networking by removing abstractions and building pieces myself.

HTTP servers and clients from scratch, TCP/UDP experiments, DNS, proxies, connection management, protocol parsing, backpressure, timeouts, and other networking concepts — using Java, Go, C, or whatever language best fits the experiment.

Small, isolated experiments around distributed systems, resilience, messaging, consistency, observability, and cloud-native architecture.

Rather than only implementing the happy path, these experiments deliberately introduce failures: duplicate messages, retries, service crashes, latency, unavailable dependencies, partial failures, and inconsistent state.

Topics include:

Idempotency · Retries & Backoff · Circuit Breakers · Sagas · Transactional Outbox · Messaging · Eventual Consistency · Observability · Chaos Engineering

My workspace for learning Go through projects, experiments, and personal notes.

I'm particularly interested in Go for networking, infrastructure, backend services, concurrency, and distributed systems.

I'm especially interested in the layers where application development meets systems engineering:

• ☕ Java & the JVM — runtime behavior, JIT compilation, allocation, GC, profiling and performance
• 🧠 Algorithms & data structures — implementation details, memory layout and performance characteristics
• 🌐 Networking — TCP/IP, HTTP, DNS, sockets, proxies and what happens beneath high-level clients
• 🌍 Distributed systems — consistency, messaging, coordination, resilience and failure modes
• ☁️ Cloud-native systems — AWS, containers, infrastructure, observability and distributed application architecture
• ⚙️ Performance engineering — measurement, profiling, benchmarking and understanding bottlenecks
• 🐹 Go — learning the language through systems-oriented projects

Backend & Languages

Java · TypeScript · JavaScript · PHP · Go · C

Application Development

React · Next.js · Laravel

Systems & Infrastructure

Linux · Docker · AWS · Git

I learn best by turning concepts into experiments.

Instead of only reading about something like retries, hash tables, GC behavior, or TCP connections, I prefer to:

1. build a small implementation;
2. form a hypothesis;
3. create a reproducible experiment;
4. inspect or measure what actually happens;
5. deliberately introduce edge cases and failures;
6. document what I got wrong and what I learned.

A lot of the repositories here are built around that process.

I'm also working toward a larger cloud-native neobank project where I'm intentionally choosing a more distributed architecture than the problem strictly requires.

The goal is educational: use a single system to bring together concepts such as service boundaries, messaging, consistency, failure handling, observability, AWS infrastructure, and distributed workflows.

In a production system I would generally favor the simplest architecture that satisfies the requirements.

Here, the architectural complexity is part of the experiment.

I'm interested in understanding software all the way down — not only how to use an abstraction, but what it does, why it works, and how it fails.