Topic
11 articles on System Design, written from production systems rather than documentation.
Moderating what users send is the familiar half. Moderating what your own product says, in your name, is the half that carries the liability.
Teams reach for fine-tuning to make a model know their data. It is much better at teaching behaviour, and facts have a cheaper home.
People are the only judges who catch what nobody thought to check for. Spending that attention on random samples wastes most of it.
The capability gap narrows every few months. What does not narrow is the difference in who controls deprecation, data residency and your cost curve.
Embeddings capture how text is used, not what it means. That distinction explains most of the retrieval failures that look inexplicable from the outside.
Most problems described as agent problems are retrieval, a workflow, or a form. Agents earn their cost in a narrow band, and it pays to know where it starts.
Without evals you cannot tell an improvement from a regression, so every change becomes an argument. That is a team problem before it is a quality one.
Cron jobs and reprocessors are trivial with one replica and dangerous with three. Leader election lets multiple replicas run without duplicating one-off work.
CAP theorem is usually taught as an abstract triangle. In production it's one question: what should this service return when it can't reach another node?
Batching helps throughput and hurts latency. Caching helps latency and can hurt consistency. Most performance debates are about which number matters more.
Attaching a second container to handle logging, mTLS, retries and observability, so your main service doesn't have to. When a sidecar earns its overhead.
Whether it needs designing from scratch or rescuing from its own success, tell me what you’re building and I’ll tell you how I’d architect it.
Open to remote and hybrid work worldwide