🌐 This lesson is available in Chinese only for now. English and German translations are planned for Week 46.

365 Days to Full-Stack · PHASE 1 · WEEK 1

Day 1 - How Does a Backend Server Handle Many People at Once?

Time: 3 hours (learn 50 min + hands-on 100 min + notes 30 min) · Topic: Concurrency Models — the first pillar of the backend world · Language: Node.js (just a tool; concepts are what matter)

🍜 The Noodle Shop Analogy: Why Backend Cares About Concurrency

You open a noodle shop. Rush hour hits and 100 people pour in at once. You have one stove. What do you do?

This is the core problem of backend concurrency: how to serve many requests with limited resources.

📇 Concept Card: Concurrency ≠ Parallelism

Concurrency: One person (server) juggling many tasks by switching between them. Looks like multitasking.
Parallelism: Many people working at the exact same time. Needs multiple cores.

Node.js uses concurrency (one person, many tasks). Java/C# use parallelism (many threads). Go uses lightweight concurrency (goroutines).

👥 Three Staffing Plans = Three Concurrency Models

Plan A: Hire Many Staff (Multithreading)

One server per request. Java/C# tradition. Problem: expensive, doesn't scale past a few thousand requests.

Plan B: One Smart Waiter (Event Loop)

One person. Never idle. Takes orders, gives them to the kitchen (callbacks), comes back when ready. Node.js way. Scales to millions.

Plan C: Lightweight Coroutines

Thousands of cheap "fibers". Go's goroutines. Switch context super fast.

Bottom line: Concurrency is a runtime strategy, not a language choice. You can do it any way in any language. Node.js picks event loop because it's the cheapest for I/O-heavy work.