Backend Engineer · Java · Spring Boot · Python · AI Systems
I build systems that stay correct when load, retries and partial failure all show up at once.

I build backends in ☕ Java and Spring Boot, and 🐍 Python services and AI systems with FastAPI. Across both, I'm drawn to the parts of a system that are easy to get subtly wrong — caching, messaging, idempotency, billing, consistency under concurrency.

🤖 On the AI side my interest isn't prompt-wrangling, it's making a non-deterministic component trustworthy enough to ship: closed output schemas per agent, verification enforced in code rather than in instructions to the model, grounding checks that kill invented numbers before a user sees them, and an eval harness that tells me when a change made things worse. Multi-agent orchestration with LangGraph, retrieval and analytics over DuckDB, streaming over SSE — built with the same discipline I'd apply to a payments service.

🔨 Most of what's below was built from first principles rather than assembled from a tutorial: a cache with its own wire protocol, a link service that has to bill every single visit, an analytics agent that refuses to answer when the data can't support it. Every README explains the reasoning and what got traded away — including the decisions that didn't pan out.

A sharded, in-memory key–value cache written from scratch in Java — a minimal Redis. Consistent hashing with 200 virtual nodes per physical node, 32 lock-striped partitions, pluggable LRU/LFU eviction, TTL expiry, and a 12-byte binary protocol over non-blocking NIO. A client can hit any node; keys owned elsewhere are forwarded one hop and relayed back.

📊 Benchmarked at two levels, which turned out to be the interesting part. The core data structure does ~4.9M gets/sec in-process under JMH with 8 threads. End-to-end over TCP it plateaus near 30K ops/sec — the bottleneck is the single NIO selector thread serialising every request onto one core, not the cache itself. The README walks through p50/p99/p99.9 at each concurrency level and why the tail climbs.

Java · NIO · JMH · consistent hashing · lock striping

A URL shortener built around a requirement that makes it genuinely hard: every visit has to be billable. That forces decisions a create → redirect service never faces — counting visits asynchronously through Kafka instead of writing a row per click, a cache-first read path, idempotency on writes, and immutable invoices over plan tiers.

📐 There's a separate ARCHITECTURE.md covering the why behind each component and what was given up to get it.

Java · Spring Boot · Kafka · PostgreSQL · Redis

Spring Boot service that publishes and consumes notification events over Kafka across email, SMS and push channels, using the outbox pattern so a delivery isn't lost when the database commit and the broker publish disagree. The README has a Decisions & Tradeoffs section rather than just setup steps.

Java · Spring Boot · Kafka · outbox pattern

Two agent systems, both built so the model can't fabricate its way past the guardrails.

Ask a question in plain English, get back the statistic, the SQL that produced it, the rows it came from, and a verification pass confirming every number in the answer actually exists in those rows. When the data can't answer the question, it says so — refusing is treated as a normal, correct output.

Six agents on LangGraph (Router → SQL Analyst → Reviewer → Narrator → Viz) over DuckDB, behind FastAPI and a React + TypeScript frontend, Dockerised into one command.

🔒 What keeps it honest, all enforced by code:

• A sqlglot AST guard — single read-only SELECT, one table, every referenced column must exist; failures are fed back for retry
• Number grounding — any figure the narrator invents dies before it reaches the user
• A hand-written semantic layer plus coverage computed from the live database at startup, so nothing about the dataset is hard-coded
• Prompt-injection defence — data cells are sanitised and framed as data before entering any prompt
• 98 offline tests and an eval harness with golden cases scored against truth SQL, comparing by value so any equivalent query passes, with ▲▼ deltas against the previous run

Python · LangGraph · DuckDB · FastAPI · React · sqlglot · pytest · Docker

Turns a loose idea — "10 days in Thailand, I like beaches and food" — into a real day-by-day itinerary: which cities and in what order, where to stay each night, named stops with commute legs and fares, day-by-day weather on real dates, and a transparent cost breakdown fetched via tool calls rather than guessed. It plans a single city, a country, or a whole continent.

🛡️ Every place is verified against real geo data, and a Critic step enforces the exact day count and flags ungrounded output before repairing it. The whole agent pipeline streams live over Server-Sent Events so you can watch it work. If the LLM or any upstream API is down it degrades to curated data instead of crashing.

Python · FastAPI · SSE · OpenAI · React · TypeScript · OpenStreetMap · Open-Meteo

Languages

Backend

Data & messaging

AI

Frontend

Testing & infra

📫 LinkedIn · dineshchahar4666@gmail.com · 📍 Delhi, India