About · the writer
Jagdish Salgotra
Principal engineer. Fifteen years building systems where latency and correctness are constraints, not goals.
Fifteen years building production systems: JVM performance and concurrency, low-latency search, Kafka stream processing, and subscription and charging platforms where being wrong costs money. Lately, a lot of applied AI.
Most systems don't fail because engineers don't know enough. They fail because decisions made at speed, under pressure, with incomplete information were never honest about their tradeoffs.
This is where I write down whatever I'm wrestling with: virtual threads, structured concurrency, tail latency, load control, and lately agentic AI. Runnable experiments, checked-in CSVs, negative results included.
I also built the in-page reader companion. It reads every article here and answers questions in the same language, grounded in the post you're on. Constrained on purpose: every answer cites its source.
What I work on
JVM performance and structured concurrency. Low-latency search on OpenSearch. Kafka stream processing. Subscription and billing systems where correctness is regulated rather than optional: sequential invoice numbering under GST, idempotent payment-gateway webhooks, consent and erasure under the DPDP Act.
Lately, applied AI in production: retrieval grounding, evaluation, and what breaks when an LLM feature meets real traffic.
How I work
five practicesI write tests after the bug, not before it.
A test pins the fix in place so the same bug cannot come back quietly. A failing test is the most useful thing a bug report can hand me.
I keep a runbook for every service I run.
If I can't write down how to restart it, recover from corruption, and read its logs on a bad day, I shouldn't be running it on a good one.
I prefer one boring deploy a week over ten clever ones.
Cleverness compounds quietly, in the form of pages at 2am. Boring deploys are the dividend of having thought ahead.
I read the postmortem before I read the docs.
The docs tell you what the system is supposed to do and the postmortem tells you what the system actually did under pressure. The second one is usually the more honest teacher.
I pin abstractions to a concrete problem first.
A second use case for the abstraction is when I add a parameter; a first one is when I write a comment instead. The premature abstractions I’ve regretted all had a confident parameter and a vague comment.
Let’s connect
Email is open.
Most interested in production failure modes, concurrency, applied AI, and what broke for you last week.