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.
15 articles
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.
Monitoring Distributed Systems
The Google SRE book chapter, written by Rob Ewaschuk and edited by Betsy Beyer, that introduced the "four golden signals": latency, traffic, errors, and saturation, as the minimum viable dashboard for any user-facing service. What's held up is the discipline behind it: pick a small number of signals you'll actually look at during an incident instead of a wall of graphs nobody reads at 3am. I still use this as the starting checklist whenever I'm setting up monitoring for a new service.
Caching challenges and strategies
Matt Brinkley and Jas Chhabra lay out the uncomfortable truth about caches: they don't just add latency and cost benefits, they change your system's failure modes, because a cold or unavailable cache can dump surge traffic straight onto a downstream service that was never sized for it. The taxonomy here, local vs. external, inline vs. side, and how each fails differently, is one I still reach for when reviewing a caching design. Worth reading before you add a cache "for performance" without thinking through what happens when it goes away.
The Tail at Scale
The paper that explains why your p50 latency dashboard is lying to you: at scale, it's the tail — p99, p999 — that decides whether users experience your service as fast, because any single request has to survive every slow component in its path. Dean and Barroso's techniques for taming it, especially hedged and tied requests, are still the starting point for anyone designing a fan-out call pattern or arguing for stricter SLOs on a critical dependency. Dense, but every page earns its place — required reading before you design anything with fan-out on the critical path.