Backend Systems · Distributed Systems · Cloud Infrastructure · AI Agents
I compile messy product ideas into APIs, workers, queues, and deployable systems — with boring reliability, observable failure modes, and architecture another engineer can debug.
backend systems / queues / caches / logs / deploys
mode: curious systems gremlin · logs before vibes · retries with budgets · ship, observe, tighten
I work on the parts of software that keep running after the happy-path demo ends: API boundaries, worker queues, cache strategy, schema design, background jobs, deployment scripts, logs, and failure paths.
Current direction: Backend engineering with Java/Spring Boot, Node.js/TypeScript, Python, PostgreSQL, Redis, messaging systems, Docker/Kubernetes, and practical AI-agent workflows.
mental model: product flow -> API contract -> data model -> failure modes -> observability -> deploy
[services]Designing production-oriented backends with explicit contracts and boringly reliable APIs.[distributed]Studying retries, idempotency, queues, caching, consistency, and the failure modes between them.[runtime]Going deeper with Kafka/RabbitMQ, Redis, Kubernetes, observability, and secure cloud deployment.[agents]Building retrieval workflows and developer tools that automate real engineering work.[interviews]Practising DSA, LLD, and system design for SDE/backend roles.
build → observe → break → debug → improve → automate
workflow: real— wire the actual path instead of hardcoding the demo.failure_mode: expected— budget retries, set timeouts, degrade gracefully, and leave useful logs.complexity_budget: guarded— keep the architecture legible before making it clever.non_functionals: first_class— security, reliability, and observability ship with the feature.done: verified— evidence before victory laps.
request -> auth -> validate -> queue/cache -> db -> emit event -> trace/log/metric
| If the system has... | I start asking about... |
|---|---|
| APIs | contracts, validation, idempotency, versioning, rate limits |
| Queues | retries, ordering, poison messages, replay, duplicate handling |
| Databases | indexes, transactions, migrations, connection pools, slow queries |
| Caches | invalidation, TTLs, stampedes, consistency, fallback paths |
| Deployments | health checks, rollbacks, config, secrets, observability |
|
Backend Java · Spring Boot · Node.js · TypeScript · Python · FastAPI · Express.js · REST APIs |
Data + Messaging PostgreSQL · MySQL · Redis · Kafka · RabbitMQ · MongoDB · database design |
Infra + Cloud Docker · Kubernetes · Nginx · GitHub Actions · AWS · Vercel · Linux |
Engineering interests: distributed systems · system design · observability · reliability engineering · event-driven architecture · AI agents · developer experience
- Worked across backend, automation, and cloud-platform software engineering contexts.
- Built and validated REST APIs, service workflows, CI/CD-integrated checks, and database-backed systems.
- Worked with recovery-oriented flows: health checks, failover thinking, alerts, and operational readiness.
- Collaborated across software engineering, DevOps, and product boundaries while keeping implementation details appropriately scoped.
Writing notes on: idempotent APIs, Kafka delivery semantics, Redis rate limiting, database indexing, Kubernetes probes, distributed locks, retry/backoff strategies, DNS, networking, API reliability, LLD, and system design.
currently poking at: outbox pattern, backpressure, dead-letter queues, cache stampede control, trace IDs
reliability = good defaults + observability + graceful failure