DRY · KISS · YAGNI — System Design

TL;DR

DRY (Don't Repeat Yourself) — every piece of knowledge should have one authoritative source. KISS (Keep It Simple, Stupid) — the simplest design that works is usually right. YAGNI (You Aren't Gonna Need It) — don't build for hypothetical futures. They tug against each other on purpose; the discipline is knowing which one to apply when.

When to use

On every code review and every design doc. These three are the cheapest senior-engineer filter you can run against a proposal — if the design fails any of them, you usually haven't found the right design yet.

Try it

DRY — the rule, and the trap

Don’t Repeat Yourself. Every fact about your system should have one source of truth. Duplicated logic = duplicated bugs.

KISS — the rule, and the trap

Keep It Simple. The simplest design that solves the problem is almost always the right one. Complexity has a maintenance bill that compounds.

YAGNI — the rule, and the trap

You Aren’t Gonna Need It. Don’t build features, abstractions, or flexibility for use cases you don’t have yet.

How they interact

                  DRY → reduce duplication
                   ↑
                   |
  YAGNI ← (tension) → KISS
                   |
                   ↓
            Don't add what you don't need (yet)

In system design interviews

These three explain why most candidate designs lose points:

Over-engineering (YAGNI failure) — adding caching, queues, sharding before justifying the load.
Under-engineering (KISS failure) — three undocumented hacks that work for the demo but won’t survive on-call.
Premature abstraction (DRY failure) — a generic event-bus framework when one POST endpoint would do.