Common System Design Mistakes
Many system design failures — both in real production systems and in interviews — trace back to a small set of recurring mistakes rather than genuinely novel errors. Recognizing these patterns is often more valuable than memorizing more architectures, because avoiding them improves judgment across every design problem, not just one specific one. The mistakes span three broad categories: skipping the requirements/estimation phase, mismatching architectural complexity to the actual problem, and treating hard distributed-systems tradeoffs as solved rather than genuinely constrained.
Cricket analogy: A team that loses repeatedly to the same type of left-arm spin bowling isn't facing a new problem each time — it's the same recurring weakness, and a coach who drills the specific fix improves the team's game against every left-arm spinner, not just the next match.
Skipping requirements and jumping to architecture
The most common mistake, especially under time pressure, is starting to draw boxes and arrows before establishing what the system actually needs to do and at what scale. A design optimized for 10,000 users looks different from one optimized for 100 million users — sharding, caching, and even the choice between SQL and NoSQL often depend directly on scale that was never established. Similarly, skipping the functional-vs-non-functional split (what must the system do, versus what quality attributes — availability, latency, consistency — must it have) leads to architectures that satisfy neither well, because tradeoffs were made implicitly rather than deliberately.
Cricket analogy: A club captain who sets a batting order before knowing whether it's a 20-over thrash or a 5-day Test is setting the team up to fail — the whole strategy, from aggression to fielder placement, depends entirely on the format and stakes that were never established first.
Over-engineering and under-engineering
Over-engineering shows up as reaching for microservices, message queues, and multi-region active-active replication for a system that a single well-indexed relational database and one caching layer could serve comfortably — complexity has a real cost in operational burden and failure modes, and it should be justified by an actual requirement, not defaulted to because it's 'best practice.' Under-engineering is the opposite failure: assuming a single database and single server will scale indefinitely, ignoring that read/write patterns, data growth, or availability requirements will eventually force a redesign. The skill being tested is matching architectural complexity to the actual stated (or reasonably inferred) requirements — not defaulting to either extreme.
Cricket analogy: A club-level weekend team hiring a full-time analytics department and a specialist fielding coach for every position is wasted complexity; a national team relying on a single generalist assistant coach for a World Cup campaign is under-resourced for the stakes involved.
A very common concrete instance: designing a rate limiter or feed system with a single, unsharded counter or table 'for now' with no articulated plan for how it would be sharded or replaced once it becomes a bottleneck. Even if a simple initial design is the right call, being unable to explain what would break first and how you'd address it demonstrates a lack of depth, not appropriate simplicity.
Mishandling distributed-systems tradeoffs
A frequent and serious mistake is treating consistency, availability, and partition tolerance as if a system could have 'all of them' without a real tradeoff, or claiming strong consistency and low latency simultaneously across geographically distributed replicas without acknowledging the physical limits (network latency, the CAP theorem) that make this impossible in general. Related to this is false precision: stating a cache hit ratio of exactly '99.97%' or a latency of 'exactly 4ms' without any basis is worse than giving a qualitative, correctly-reasoned range, because it signals the number was invented rather than derived from real constraints. Good design communicates uncertainty honestly — 'this should give us a high cache hit ratio given the access pattern is likely to be skewed, though I'd want to validate that empirically' is more credible than a fabricated decimal.
Cricket analogy: Claiming a batting lineup can have maximum aggression, zero risk of losing wickets, and a guaranteed run rate all at once ignores that these genuinely trade off against each other; a captain who instead says 'we can push the run rate but accept more wicket risk, or bat safe and accept a slower rate' is being honest about the real tradeoff.
Quick self-check before finalizing a design:
[ ] Did I clarify scale (users, QPS, data volume) before proposing components?
[ ] Does architectural complexity match the stated requirements, not a default 'best practice' stack?
[ ] Have I named the specific tradeoff behind each major decision (e.g., consistency vs availability, cache freshness vs hit ratio)?
[ ] Are my numeric estimates qualitative/order-of-magnitude, not falsely precise?
[ ] Can I explain what breaks first as scale grows 10x, and what I'd change?
[ ] Have I distinguished functional requirements from non-functional ones explicitly?A well-known real-world instance of under-engineering-turned-crisis is any 'went viral overnight' story where a single relational database with no read replicas or caching layer buckles under sudden 100x traffic — the postmortems for these incidents consistently point back to the same root cause: no one had identified in advance what would break first, so there was no pre-planned mitigation to reach for under pressure.
- Skipping requirements gathering and capacity estimation before proposing architecture is the single most common root-cause mistake.
- Over-engineering adds unjustified operational complexity; under-engineering ignores foreseeable growth — both stem from not matching complexity to actual requirements.
- Claiming a system avoids fundamental tradeoffs (e.g., 'strongly consistent and always available across regions') signals a misunderstanding of distributed systems constraints like the CAP theorem.
- False numeric precision (invented exact percentages or millisecond figures) is less credible than honest, correctly-reasoned qualitative estimates.
- A resilient design explicitly identifies what would break first under 10x growth and has a stated mitigation, even if the initial design is intentionally simple.
- Distinguishing functional from non-functional requirements early prevents architectures that implicitly and poorly compromise on both.
Practice what you learned
1. What is identified as the most common root-cause mistake in system design?
2. What distinguishes appropriate simplicity from under-engineering in a design?
3. Why is claiming a system is both strongly consistent and always available across geographically distributed replicas considered a mistake?
4. Why is false numeric precision (e.g., an invented '99.97% cache hit ratio') considered worse than a qualitative estimate?
5. What is the core skill being tested when evaluating whether a design is over-engineered or under-engineered?
Was this page helpful?
You May Also Like
The System Design Interview Approach
A structured framework for tackling open-ended system design interview questions, from requirement gathering through high-level design, deep dives, and trade-off discussion.
The CAP Theorem
A foundational result stating that a distributed data store can only guarantee two of consistency, availability, and partition tolerance at once, shaping every distributed database's design.
Scalability Fundamentals
Core concepts behind building systems that handle growing load gracefully, including scaling dimensions, bottleneck identification, and the diminishing returns of naive scaling.
System Design Interview Questions
A curated set of representative system design interview prompts across difficulty levels, with notes on what interviewers are actually evaluating for each.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics