Most discussion of enterprise AI is about models. This post is about the layer underneath them, the data infrastructure that quietly decides whether any of that AI actually works, and it builds up from the ground.
Software engineer working on large-scale distributed systems, big data, and AI infrastructure. Currently at Microsoft.
Most discussion of enterprise AI is about models. This post is about the layer underneath them, the data infrastructure that quietly decides whether any of that AI actually works, and it builds up from the ground.
First in a series that works through classic system design interview questions the way I actually run them, on both sides of the table. Every post follows the same six beats: clarify, estimate, define the API, sketch the design, dive into the hard part, and break it. The rate limiter is the perfect opener because it looks trivial and is not.
There is a particular kind of investment that feels better than it is: the kind that pays you. A dividend lands in your account. A tenant wires rent on the first. A bond coupon shows up like clockwork. Nothing had to be sold, no button had to be pushed, and yet money appeared. It feels like the asset is working for you in a way that a rising index number never quite does.
“Operational excellence” is one of those phrases that has been said so many times in so many all-hands meetings that it has stopped meaning anything. It sounds like a virtue, something you achieve by caring a lot and trying hard. It is not. Operational excellence is a set of concrete engineering practices built on top of a few numbers, and the numbers are unforgiving. This post is about those numbers and what they actually demand, written for someone who has heard “five nines” thrown around and wants to know what it really costs.
You type a hostname into a browser, the little lock icon (the padlock) appears in the address bar, and a page loads. It feels like one thing. It is really a short, ordered sequence of independent systems, each of which has to be correct, and each of which fails in its own recognizable way.
Your video call freezes for three seconds, then recovers. Somewhere, in the network between you and the other person, something went briefly wrong. The interesting question for an engineer is: could anyone actually prove what happened, after the fact? Answering that turns out to be a data problem, and a surprisingly large one. The systems that watch a network for a living generate a torrent of data about it, and handling that torrent well is the same kind of high-throughput data-infrastructure challenge I usually write about in the context of AI. This post is about why network monitoring is, underneath, a big-data problem, and why the hard parts rhyme with the hard parts of feeding data to AI.
A junior engineer reached out to me recently. They were stuck in a job with bad management, mentally fried, and wanted out — but the idea of grinding interviews on top of a draining day job felt impossible. They asked how I balanced shipping work, prepping for interviews, and actually passing the loops. I’ve also sat on the other side of the table as an interviewer, so I have opinions about what works and what gets people rejected.
An earlier post made the case for why to invest. This post is the operating manual: how to turn a steady income into an actual portfolio you can run for decades. It’s written to be read top to bottom whether or not you’ve invested before. It starts with the simple, country-agnostic framework (concepts, no tickers), then works the same idea out as a concrete U.S. allocation. The exact funds are collected in one section at the end. The strategy’s core, the discipline, and the behaviors are what matter most; the exact tickers matter the least
Many teams shipping retrieval-augmented generation today started from the same five-line tutorial: chunk your documents, embed them into a vector store, embed the user’s question, fetch the nearest hits, hand them to an LLM. It works beautifully in a notebook. It also has almost nothing to do with what a real RAG product looks like once it has users.
One reason — if you can see the world a little more broadly, can calculate risk, and can plan long-term, you can see that this rat race actually has an exit.
GitHub Pages on the Free plan only builds from public repos. To keep your source private, GitHub charges $4/month for Pro. Here’s how to get the same result for $0 by splitting source and built output into two repos.