What Is System Design

What System Design Actually Is

Coding produces logic. System design decides how many independent parts exist, what each owns, and how they talk — then justifies those choices against scale, failure, and cost. A working app is not the output; a working app that survives 100x growth and partial failure is.

The discipline spans three altitudes:

 ALTITUDE        QUESTION ANSWERED                  ARTIFACTS
 ────────────────────────────────────────────────────────────────────
 System (HLD)    Which services exist? Where does   Architecture diagram,
                 data live? How does it scale?      component contracts,
                                                    estimation sheet
 ────────────────────────────────────────────────────────────────────
 Component       Inside one service: APIs,          API spec, schema DDL,
                 caching, queues                    sequence diagram
 ────────────────────────────────────────────────────────────────────
 Code (LLD)      Inside one component: classes,     Class diagrams, code
                 patterns, algorithms               review

HLD lives at the top altitude but must stay consistent with the lower two — an architecture nobody can implement is fiction; an architecture that ignores class-level reality is worse.

The Decisions System Design Makes

Every design answers the same recurring questions. Good designs make the answers explicit; bad designs leave them implicit until production discovers them.

Question	Example answer
Decomposition	One monolith now; extract matching service when X triggers
Data placement	Postgres as source of truth; Redis for sessions
Communication	Sync REST internally; async queue for notifications
Scaling axis	Reads via replicas + CDN; writes sharded later
Failure posture	Multi-AZ active-passive; RPO 5 min

Why Scale Changes Everything

Techniques that work at small scale silently die under load — none of these are bugs, they are physics:

 1 app + 1 DB                     10k writes/sec

 Client → App → Postgres          Client → LB → App × N → ???
 works forever                    single Postgres saturates:
                                  - one writer (replicas help reads only)
                                  - connection count explodes with N apps
                                  - index writes serialize on hot tables

                                  forces: write path redesign → queues,
                                  batching, then sharding — each a real
                                  architectural decision

In-process state dies the moment two app servers sit behind a load balancer. Naive joins die when tables hit billions of rows. Disk seeks cost ~ms while memory access costs ~ns — five orders of magnitude that dictate where data lives.

The Shape of Every Design Exercise

Regardless of problem — URL shortener or YouTube — the same loop repeats:

 requirements → estimates → baseline design → find weaknesses
      ▲                                           │
      └─────────── iterate ◄── apply fixes ◄──────┘

Requirements anchor everything. Estimates turn vague scale into numbers (“100M users” becomes “~1,200 rps peak”). The baseline gives something concrete to attack. Iteration converges on a defensible design.

Interview Framing

System design interviews grade the loop, not the destination: clarify, estimate, propose, defend trade-offs, adapt when pushed. Seniority shows as knowing why each box exists and naming what breaks first when load doubles.