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.
9 articles
Why Discord is switching from Go to Rust
Jesse Howarth's account of Discord replacing a hand-tuned Go service with Rust because of GC-driven latency spikes their garbage collector kept reintroducing no matter how much they tuned it, and Rust, even in a fairly unoptimized first pass, beat it on latency, CPU, and memory all at once. It's a useful data point in the "when does garbage collection actually matter" debate, precisely because Discord weren't chasing a rewrite for its own sake; they had one specific, isolated, latency-sensitive service where GC pauses were directly user-visible. Refreshingly narrow in scope rather than a blanket "Rust is better" argument.
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.
Microservices
The essay that put a name and a definition to an architectural style most of us were already half-doing by instinct — nine characteristics, from componentization via services to decentralized data management, laid out with none of the conference-talk hype the term later picked up. What holds up more than a decade later is the honesty about the cost side: microservices trade simplicity for operational complexity, and Fowler and Lewis say so plainly rather than selling it as a free upgrade. If you only ever read one primary source before an architecture debate about services vs. monolith, make it this one.
CQRS
Fowler's short bliki entry on Command Query Responsibility Segregation is the one to read before anyone on your team gets excited about splitting reads and writes into separate models, because his real point is restraint: CQRS earns its complexity in specific, collaborative-domain contexts, not as a default. I've seen it misapplied to plain CRUD systems more than once, and this piece is the fastest way to talk a team back from that. Short, opinionated, and still the reference everyone eventually cites.