About · the writer
Jagdish Salgotra
Distributed-systems engineer. Fifteen years across the production stack.
Fifteen years building production systems, JVM perf, concurrency rollouts, low-latency search, infrastructure, and lately a lot of applied-AI work.
This site is where I write down whatever I'm wrestling with at the time.
I also built the in-page reader companion. It reads every article here and answers questions in the same language. Constrained on purpose: every answer cites the source post.
Across the engineering stack at work: fan-out service architecture, the Java concurrency story, low-latency search pipelines on OpenSearch, Kafka stream processing, and infrastructure work along the way. Lately, a lot of applied AI: RAG systems, retrieval grounding, and operating LLM features in production. The notebook reflects whatever I’m closest to that month.
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.