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.
42 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?
Gergely Orosz, writing for The Pragmatic Engineer, drawing on Nicky Wrightson's (a former principal engineer) account of what actually 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.
Rebuilding messaging: How we designed our new system
Tyler Grant, Armen Hamstra, and Cliff Snyder open LinkedIn's messaging-rebuild series with the design phase: why a decade-old messaging system built for one use case couldn't cleanly extend to InMail, group chat, and integrations, and the architectural bets, a GraphQL API paired with a real-time stream, they made instead. What I find useful here is how much of the piece is about defining the problem precisely before touching the solution, a discipline that's easy to skip once a rewrite already has momentum behind it. Worth reading as a template for how to open a rewrite proposal, not just a rewrite postmortem.