Lean System Design: Prioritizing Simplicity and Real-World Requirements
This article introduces "Lean System Design," an approach advocating for building systems with minimal complexity tailored to explicit, measurable requirements, rather than automatically defaulting to complex distributed systems popularized by big tech. It highlights the common pitfall of over-engineering for non-Google scale problems, emphasizing cost efficiency, operational simplicity, and appropriate scalability. The piece encourages a critical evaluation of system needs and the actual limits of single-machine architectures before opting for distributed solutions.
Read original on Dev.to #systemdesignThe Pitfall of Google-Scale Thinking
The article critiques the widespread assumption that all systems require the complex distributed architectures used by large tech companies like Google. This mindset often leads to over-engineering, unnecessary costs, slower development, and increased maintenance overhead for most businesses that will never experience traffic volumes requiring such solutions.
What is Lean System Design?
Lean System Design is defined as the design of systems to meet explicit requirements with minimal complexity, focusing on measurable requirements, system-lifetime-aware decisions, long-term cost efficiency, and operational simplicity.
Understanding Real-World System Requirements
For most applications outside of hyperscale environments, system requirements are often far more modest than anticipated. Engineers should accurately assess their needs based on numbers rather than following popular trends. Typical real-world requirements include:
- 10 to 1000 RPS (requests per second), not millions.
- Latency and availability targets for ordinary users, not sophisticated SLAs.
- Per-use-case data correctness guarantees.
- High operability and maintainability for easy diagnosis and fixes.
- Limited infrastructure and personnel costs.
The True Benefits and Costs of Distributed Systems
Distributed systems inherently introduce complexity, particularly around consistency and availability. While they offer near-infinite scalability, other perceived benefits like better team scalability or clearer domain separation are often coincidental byproducts of microservices adoption, not inherent to distributed architectures themselves. These factors should not solely drive the decision to go distributed.
When to Choose Distributed Architectures
- Clear Scalability Needs: When an in-depth analysis of expected load and growth (numbers) demonstrates that a single machine cannot meet required scalability targets.
- Leveraging Existing Stable Systems: When integrating a self-contained, stable distributed system (e.g., a distributed database) where much of the complexity is abstracted away, but still recognizing the remaining integration challenges.
- Interview Preparation: A tongue-in-cheek reason, highlighting the disconnect between interview expectations and real-world system needs.
Powerful Single-Machine Examples
The article cites Stack Overflow and GitHub Pages as historical examples of highly successful, high-traffic systems that initially ran on surprisingly simple, single-machine (or near single-machine) architectures for many years, serving millions of users effectively without complex distributed setups. This demonstrates the often underestimated capabilities of well-optimized monolithic or single-instance solutions.