I build backend systems, distributed services, and cloud-native platforms with a focus on performance, reliability, scalability, and data-intensive workloads.

My professional work is primarily in enterprise banking, where I work across application architecture, backend services, platform engineering, performance analysis, observability, and data systems.

Outside of work, I build and contribute to systems software, caching, networking, search, and distributed-systems projects, mainly using Zig, Java and C#.

Designing and evolving cloud-native backend systems for enterprise banking applications.

• Microservice architecture and service design
• High-volume transaction processing
• Event-driven architectures
• Backend performance engineering
• Distributed service communication
• Data-intensive processing and analytics
• Production observability and troubleshooting
• Kubernetes/OpenShift-based deployments

I work across both application and infrastructure layers to identify bottlenecks and improve system performance.

Some areas I work with:

• Latency analysis
• Throughput benchmarking
• Database performance
• Service communication overhead
• Thread and worker utilization
• Distributed tracing
• Resource utilization
• Performance automation and analysis

I particularly enjoy understanding why a system becomes a bottleneck under load, rather than only optimizing individual components.

I'm interested in systems where correctness, scalability and failure handling matter.

Current areas of exploration:

• Distributed consensus
• Raft / Multi-Raft
• Replication
• MVCC
• Optimistic concurrency
• Messaging systems
• Distributed storage
• Caching
• High-performance networking
• Service-to-service communication

Production banking systems are proprietary, so the descriptions below intentionally avoid confidential implementation details.

Worked on a high-volume transaction classification platform used for personal financial management.

Engineering areas:

• Transaction ingestion and validation
• Classification pipelines
• PostgreSQL-backed processing
• ML + rule-based classification
• Batch processing
• Data quality and error handling
• Multi-bank deployment architecture
• Performance benchmarking
• Production rollout

Contributed across the lifecycle from POC → MVP → QA qualification → client deployment.

Worked on backend services and analytics infrastructure for application behavioral analytics.

Engineering areas:

• Event ingestion
• Java/Spring backend services
• RabbitMQ-based processing
• PostgreSQL analytics workloads
• ClickHouse exploration and adoption
• Dashboard and analytics integration
• Client SDK integration
• Authentication and routing
• Observability

Contributed from POC → MVP → QA qualification → client integration.

Currently working across application and infrastructure layers to investigate performance bottlenecks and improve system behavior under load.

Areas include:

• Application latency
• Database operations
• Service-to-service communication
• gRPC
• Dapr
• Worker/thread utilization
• Distributed tracing
• Infrastructure resource usage
• Automated performance analysis using Python

A library for building fast, reliable and evolvable network services in Zig.

Built as a systems-oriented project inspired by modern high-performance networking infrastructure.

Focus areas:

• Networking
• HTTP services
• Proxy architecture
• Modular systems design
• Observability
• Performance
• Zig standard library
• Systems programming

Current development is focused on evolving the architecture while keeping the implementation lightweight and composable.

A collection of modern cache eviction algorithms implemented in Zig.

Implemented / explored:

• LRU
• W-TinyLFU
• S3-FIFO
• SIEVE
• Cache data structures
• Memory efficiency
• Eviction behavior
• Performance characteristics

The project is primarily an exploration of cache design and memory-efficient systems programming.

Contributor to the Redis OM .NET ecosystem.

Areas explored and contributed to include:

• Redis object mapping
• Bulk operations
• Redis pipelining
• Transaction handling
• Concurrency
• Documentation
• Performance-oriented operations

This work has given me practical exposure to how a production open-source data-access library is designed, maintained and evolved.

Technical contributions and exploration around Lucene internals.

Areas of interest include:

• Indexing
• IndexWriter internals
• Near-real-time indexing
• Replication
• Operation sequencing
• Concurrency
• Search engine architecture

I'm particularly interested in understanding how large-scale search systems maintain correctness and performance under concurrent workloads.

I spend a significant amount of time going deeper into the internals behind distributed and data-intensive systems.

• Raft
• Multi-Raft
• Consensus
• Replication
• Failure handling
• Distributed coordination

• MVCC
• OCC
• Transaction processing
• Storage engines
• Indexing
• Query execution
• Distributed databases

• CPU utilization
• Memory behavior
• Concurrency
• Lock contention
• Network latency
• Throughput
• Backpressure
• Queueing behavior

• Kubernetes internals
• Cloud-native runtimes
• Service meshes / sidecars
• Observability
• Distributed tracing
• Container orchestration

• TCP/IP
• HTTP/2
• gRPC
• Proxies
• Connection management
• High-performance network services

I'm exploring how AI can be integrated into real production backend systems, particularly in enterprise and banking applications.

Areas of interest:

• Applied ML
• Transaction intelligence
• LLM-powered backend services
• Agentic systems
• MCP
• AI-assisted data analysis
• Enterprise AI architecture

My focus is on combining AI capabilities with existing distributed systems, data platforms and backend infrastructure, rather than treating AI as an isolated application layer.

I like working from the bottom up:

Application
     ↓
Service Architecture
     ↓
Communication
     ↓
Concurrency
     ↓
Storage
     ↓
Operating System
     ↓
Network
     ↓
Hardware

When a system is slow, I want to understand where the time actually goes.

When a system fails, I want to understand which assumption broke.

When a system scales, I want to understand which bottleneck moved somewhere else.

• Distributed backend services
• High-performance network services
• Caches and storage components
• Data-intensive applications
• Developer tooling
• Performance analysis tools
• Cloud-native infrastructure
• Experimental systems software

I'm currently focusing on becoming a stronger Senior Backend / Distributed Systems Engineer by going deeper into:

Distributed Systems · Databases · Performance Engineering · Cloud Native · Systems Programming · Data Infrastructure

while continuing to explore:

AI/ML · MCP · Agentic Systems

I'm interested in contributing to projects around:

• Distributed systems
• Databases
• Search engines
• Networking
• Caching
• Storage engines
• Performance tooling
• Cloud-native infrastructure

If you're working on interesting systems problems, feel free to reach out.