Articles
Worth reading
A short take on pieces worth your time — architecture, AI, system design, and engineering careers — each one linked back to its original source.
22 articles
Profile-guided optimization in Go 1.21
The Go team's own writeup of profile-guided optimization landing as production-ready: feed the compiler a CPU profile from real traffic, and it makes smarter inlining decisions than static heuristics ever could, often for a meaningful throughput gain with zero code changes. What I like about this piece is how matter-of-fact it is about the mechanics — collect a profile, drop it in as default.pgo, rebuild — no framework, no magic, just the compiler using data it didn't have before. A good example of Go's philosophy of boring, composable tooling done right.
How Discord Stores Trillions of Messages
Bo Ingram's account of Discord's migration off vanilla Cassandra to a Rust-based data service layer is one of the more honest scaling stories out there — no rewrite-everything triumphalism, just a clear-eyed walk through where their original design started to show cracks at trillion-row scale and what they changed. The details on data modeling for a chat workload (message ordering, hot partitions, compaction pressure) are transferable to basically any high-write-volume, append-heavy system. One of the better "how it actually broke and what we did about it" posts I've read.
What is a Staff+ Engineer?
An honest account from someone who actually did the job — Nicky Wrightson, writing for The Pragmatic Engineer, on what changes when you move from senior engineer to staff+: less about writing more code, more about picking the right problems, being trusted with ambiguity, and, as the title says, becoming a role model whether you signed up for that or not. I recommend this to anyone plotting a technical (not management) career path who's tired of vague leveling-guide language and wants the real texture of the job. Refreshingly specific about the frustrating parts too, not just the flattering ones.
Introducing Domain-Oriented Microservice Architecture
Uber's insight here is one I wish more teams internalized before splitting a monolith: a microservice architecture is still just one large distributed program, and it benefits from the same domain boundaries and layering discipline you'd apply to any big codebase — they just happen to be enforced by network calls instead of package boundaries. DOMA's structure (domains, gateways, layers) is a genuinely useful vocabulary for reasoning about service sprawl instead of just letting it happen organically. Good read once your service count has outgrown your ability to reason about it.
Designing robust and predictable APIs with idempotency
The article that made idempotency keys a standard expectation for any payments-adjacent API: pass a client-generated key with a request, and retries — from a flaky network, a timeout, a naive retry loop — become safe instead of a double-charge waiting to happen. It's a deceptively simple pattern that solves a real and expensive class of production bugs, and this writeup is still one of the clearest explanations of why "just retry on failure" is dangerous without it. Essential if you're designing any API that touches money or triggers a side effect that can't be undone.