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
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.
Online migrations at scale
Stripe's playbook for the unglamorous but high-stakes work of migrating a live, heavily-used data model — hundreds of millions of Subscriptions objects, no downtime, no data loss allowed — without ever pausing the business to do it. The dual-write-then-backfill-then-cutover pattern they describe is the one I reach for on every schema migration of consequence, because it's the only approach I've seen actually survive production edge cases. Read this before your next "just add a migration" turns into an incident.
Why Uber Engineering Switched from Postgres to MySQL
Evan Klitzke's 2016 post is still one of the most-cited, and most-argued-about, database migration writeups out there, walking through the specific Postgres limitations Uber hit at their scale, write amplification from secondary indexes, expensive replication, and a costly process-per-connection model, that pushed them toward a MySQL-backed sharding layer. I don't take it as gospel that Postgres is worse than MySQL in general (a lot has changed on both sides since 2016), but it's a genuinely useful case study in how workload-specific tradeoffs, not general benchmarks, should drive a database choice at scale. Worth reading the pushback pieces alongside it for the full picture.
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.