# Lesson 18: Simple Beats Clever
## Roadmap
You are in **System Design Interview Prep**, Track 01, **Core Fundamentals**: lesson 18 of 19 (cost, performance and complexity trade-offs). It builds on [Lesson 17: Single Point of Failure](../17-single-point-of-failure/README.md). Next comes [Lesson 19: Stateless vs Stateful](../19-stateless-vs-stateful/README.md).
These are the written notes for the lesson's video. Prefer paper? The same notes are a free, printable PDF: [download SD-A-018.pdf](https://backendroadmap.com/notes/system-design/SD-A-018.pdf).
## Concept
> [!key] Every component costs money, operational effort and new failure modes; design for your real scale plus reasonable growth, compare designs by total cost of ownership, and keep the simplest one that meets the numbers.
## Explanation
### Every box has a price
*Figure 1. The cloud bill is the smallest part of what a component costs.*
The real cost is the **total cost of ownership (TCO)**: infrastructure plus engineering time, on-call pain and slower feature work. A design that saves 10% on servers but needs two more engineers to run it is not cheaper.
### A worked example
*Figure 2. Both designs meet the load; the simple one does it with far less to build and run.*
### YAGNI: you aren't gonna need it
Design for your real scale plus reasonable growth, perhaps 10×, not 100×. Leave clear **seams** (a data-access layer, an interface in front of the store) so you can add caching or sharding later, when the numbers demand it.
> [!model] **Triggers to add complexity.** Add sharding when the primary's write load or data size nears its limits even after scaling up; add a cache when read latency or database load misses targets; split a service when a team or a scaling need demands it. Each trigger is a number, not a feeling.
### Estimating cost per request
> [!example] **Worked example.** **Load:** 2,000 queries/s × ~2.6 M seconds a month ≈ **5.2 billion requests a month**. **Monthly cost:** add up servers, storage, network and the share of engineering time. **Divide:** say $6,000 / 5,200 million ≈ **$1.15 per million requests**. Now two designs can be compared with real numbers instead of opinions.
### Performance has a price curve
Going from 500 ms to 100 ms may be cheap: an index, a cache, fewer round trips. Going from 10 ms to 2 ms can cost a fortune: more memory, more regions, specialised hardware. Spend where users actually feel the difference, and stop when the requirement is met.
## Key terms
| Term | Meaning |
|---|---|
| **TCO** | total cost: infrastructure + people + risk |
| **YAGNI** | don't build what you don't need yet |
| **Seam** | an interface that lets you swap parts later |
| **Cost per request** | monthly cost ÷ monthly requests |
| **Operational load** | work to deploy, monitor, fix |
| **Over-engineering** | complexity beyond the requirements |
## Interview questions
Each question is tagged by kind: **Basic** (definitions), **Scenario** (apply it to a system) and **Tricky** (the follow-ups interviewers use to go deeper). Answer out loud before you open the answer.
> [!interview] When is a simpler design better, even if it scales less? (Basic)
What a strong answer covers
When it meets the real load with headroom: it's cheaper to run, easier to operate, and has fewer failure modes.
What a strong answer covers
Estimate the load, add up monthly infrastructure and people costs, and compute cost per request or per million requests.
What a strong answer covers
Don't build for scale or features you don't need yet; design for real scale plus ~10× growth, and leave seams to extend later.
What a strong answer covers
Not yet: a Postgres primary with read replicas (and maybe a cache) handles it comfortably. Shard when write load or data size approaches a single primary's limits.
What a strong answer covers
Probably overkill: a database table or a managed queue handles 50/s with far less to operate. Kafka pays off at high throughput, replay or many consumers.
What a strong answer covers
Ask what users or revenue gain, estimate the cost (memory, regions, rework), and compare. If 40 ms already feels instant, spend elsewhere.
What a strong answer covers
No. It costs money and complexity now, slows feature work, and the real bottlenecks at 100× are hard to predict. Seams plus measured triggers are safer.
What a strong answer covers
Sometimes; a single database is a SPOF. Simple doesn't mean no redundancy: keep replicas and failover, just avoid complexity the requirements don't ask for.