I don’t build CRUD apps. I build systems that survive load, concurrency, and failure.

I am a backend systems–obsessed engineer focused on how things work under pressure — threads, sockets, memory, execution models, and system boundaries.

I deliberately work below frameworks before I touch them. If a system breaks, I want to know which thread, which lock, and which assumption failed.

My mindset is simple:

• ⚙️ Understand the internals
• 🧱 Build from first principles
• 🔥 Optimize only after correctness

Long-term, I am not aiming to be “just another backend dev.” I am aiming for systems architecture, large-scale distributed platforms, and technical leadership in AI/Tech.

• Java (Advanced / Systems-Level) – Concurrency, Multithreading, JVM behavior
• SQL
• Bash

• Low-level Socket Programming (TCP/IP)
• Multithreaded Server Design
• Thread Pools (ExecutorService) & Task Scheduling
• Blocking I/O & Request Lifecycles
• REST APIs (only when appropriate)
• Spring Boot (used consciously, not blindly)

• Thread Safety & Synchronization
• Producer–Consumer Systems
• Readers–Writers Problem
• Locks, Monitors, and Shared State Control
• SOLID & Clean Architecture
• Client–Server & Layered Architectures

• Git
• Maven / Gradle
• IntelliJ IDEA
• Linux

What it actually is: A ground-up concurrent TCP server designed to handle multiple clients using a thread-pool-driven execution model, with strict separation of I/O, execution, and lifecycle control.

Why it matters: Because real backend problems start before HTTP and after concurrency.

Highlights:

• Thread-safe request handling
• Custom socket reader/writer abstractions
• Executor-backed concurrency model
• Graceful connection and shutdown handling

Concepts: Sockets · Thread Pools · Blocking I/O · Concurrency · Server Design

A backend platform designed for Java developers who hate Firebase

A blackbox system designed to stress, observe, and expose API failures under real-world conditions — without needing source code access.

What it does:

• Synthetic traffic generation at scale
• Latency, error-rate, and timeout profiling
• Failure pattern detection (cascading, partial, silent)
• SLA/SLO validation under load

Why it matters: Because most APIs work — until they don’t. This system is built to answer why they fail.

Your resume, but machine-consumable, queryable, and versioned.

Concepts:

• REST-first design
• Versioned schemas
• Structured career data
• Designed for ATS systems, recruiters, and internal tooling

Why it exists: Because PDFs are dead and backend engineers should expose themselves as interfaces, not documents.

A backend service to schedule, execute, and monitor jobs reliably at scale.

Core Challenges:

• Distributed scheduling
• Exactly-once vs at-least-once execution
• Retry semantics & failure recovery
• Time drift & execution guarantees

Why it’s hard: Because cron is easy — reliable cron is not.

A backend system that dissects infrastructure bills and explains where the money actually went.

Features:

• Service-level cost attribution
• Usage anomaly detection
• Cost-to-traffic correlation
• Actionable optimization signals

Why it matters: Because most infra costs are paid blindly, not understood.

• Advanced Java Concurrency & JVM internals
• Distributed Systems fundamentals
• System Design under real-world constraints
• Low-level networking & performance tuning

If you’re looking for shiny demos, this profile is not for you. If you’re interested in how real backend systems are built and stressed, you’re in the right place.

Serious backend engineering starts where tutorials end.