The Most Dangerous Engineer
The most dangerous engineer on a team isn't the junior. It's the one who stopped being curious, because everything underneath them keeps moving whether they keep learning or not.
notes on distributed systems, infrastructure, and production engineering
Short, practical writing on systems work: schedulers, data pipelines, observability, performance, infrastructure, and the tooling around it.
The most dangerous engineer on a team isn't the junior. It's the one who stopped being curious, because everything underneath them keeps moving whether they keep learning or not.
A distributed system is a collection of carefully managed disappointments. The engineering isn't avoiding failure, it's choosing which failures you're willing to tolerate.
AI made the obvious mistakes rare and the expensive ones invisible. Code review didn't get easier. It moved up the stack, from implementation to judgment.
AI is great at getting an app running. It is not the same as getting it ready for real users, real payments, and real data. Here is where the gap hides.
AI is another abstraction in a long line of them. The real question was never whether engineers use it, but whether they understand what they ship.
Replay storms, cost amplification, cache pressure, and backpressure — what makes a recovery design survive contact with production.
Idempotent writes, versioned aggregates, and DO NOTHING vs DO UPDATE — merging historical replay into live state without a maintenance window.
Keep collecting in realtime, but finalize behind the present. A lagged watermark is what buys you deterministic replay.
Postgres advisory locks are useful coordination primitives, but they are not durable leadership or consensus.
Observability is part of runtime architecture, not just a read-only layer over production systems.
Live processing is the easy 20% of a streaming system. Deterministic replay is the requirement everything else hangs off of.