System design rules I always come back to
The article outlines 10 reusable system design principles such as separating reads from writes, avoiding premature optimization, preferring idempotent APIs, and designing for failure. These rules help engineers build scalable, maintainable systems by learning from past mistakes and established patterns.
Background
- The article is written by Gergely Orosz, a well-known former Uber/微软 engineer who now writes the "Pragmatic Engineer" Substack, one of the most widely-read software engineering newsletters covering real-world system design and big-tech engineering culture.
- "System design" is the process of defining the architecture, components, and trade-offs of a software system (e.g., how does Instagram handle millions of uploads?). It's the most common type of interview question at FAANG (Facebook, Apple, Amazon, Netflix, Google) and other top tech companies.
- The "10 rules" are practical heuristics Orosz has refined from designing and reviewing large-scale systems at Uber and Microsoft — not academic principles, but battle-tested patterns like "prefer idempotency," "design for failure," and "keep things boring and predictable."
- Many of these rules push back against over-engineering: young engineers often reach for complex distributed systems (Kubernetes, microservices, event streams) when a simpler monolithic or queue-based design would suffice. The post is aimed at engineers preparing for senior roles or building production systems.