บทที่ 0 — System Design Mindset

สารบัญ | บทถัดไป →

---

ก่อนอ่าน — ต้องรู้อะไรมาก่อน?

⚠️ ถ้าเพิ่งเริ่มเขียนโปรแกรมจริง ๆ — หยุดก่อน

หนังสือ system design เล่มนี้ assume ว่าคุณ "เขียน code เป็นแล้ว" (เคยทำ CRUD app / REST API มาก่อน) ถ้ายังเขียนไม่คล่อง ให้ไปอ่าน Java + Spring Boot ให้จบก่อน แล้วค่อยกลับมา — เนื้อหาในนี้จะรู้สึกลอยมากถ้าไม่มีพื้นฐานการเขียนโปรแกรมจริงในหัว

บทนี้คือ "บทที่ 1 ของหนังสือ" — ผู้เขียน assume (สมมติ/ตั้งสมมติฐาน) ว่าคุณ:

• เขียน app ตัวเล็กเป็น (CRUD app, REST API) — ถ้ายังไม่เคย → กลับไปอ่าน Java + Spring Boot ก่อน
• เข้าใจคำว่า "client", "server", "database" คร่าว ๆ
• เคยได้ยินคำว่า "scale" แต่ยังไม่เข้าใจชัด

ถ้ายังเขียน code ไม่คล่อง — system design จะรู้สึกลอย เพราะไม่มี "ของจริง" ในหัวมาเทียบ

กฎทอง: อย่ามาเรียน system design เพื่อ "interview ผ่าน" อย่างเดียว — เรียนเพื่อ "คิดเป็นระบบ" — สกิลนี้ใช้กับงานจริงทุกวัน ไม่ใช่แค่วันสัมภาษณ์

---

1. System Design คืออะไร (และไม่ใช่อะไร)

ปัญหาที่ engineer ระดับกลาง ๆ ขึ้นไปต้องเจอ

ลองนึกภาพ — มี PM เดินมาบอกว่า:

"เราต้องสร้างระบบใหม่นะ — รับ user 5 ล้านคน/วัน ส่งข้อความหากันได้ ดูได้ทั้งมือถือและเว็บ ค่าใช้จ่ายอย่าให้เกิน 500K บาท/เดือน 99.9% uptime นะ"

คำถามที่เกิดในหัว engineer:

• ใช้ database อะไร?
• กี่ server?
• เก็บข้อมูลที่ไหน?
• ถ้า server ตาย จะ failover ยังไง?
• จะ scale ยังไงเมื่อ user เพิ่มเป็น 50 ล้าน?

คำถามชุดนี้คือ "System Design" — ไม่ใช่การเขียน code แต่เป็นการ "ออกแบบโครงสร้างใหญ่" ที่ทำให้ระบบทำงานได้จริงในสเกลที่กำหนด

นิยามให้ตรง

System Design = "ออกแบบระบบใหญ่ที่ทำงานได้จริง — ใน scale, budget, time ที่กำหนด"

สิ่งที่ ใช่ system design

✅ "ระบบรับ 1M user/วัน — ออกแบบยังไงให้ไม่ล่ม?"
✅ "เลือก database ไหน — แล้วเพราะอะไร?"
✅ "ถ้า traffic 10x ขึ้น — ส่วนไหนจะพังก่อน?"
✅ "Scale ได้, Reliable, Cost effective — pick 2?"

สิ่งที่ ไม่ใช่ system design

❌ "เขียน function นี้ยังไง" — เป็น low-level coding
❌ "เลือก library X หรือ Y" — เป็น tooling decision (เล็กกว่า)
❌ "Bug นี้แก้ยังไง" — เป็น debugging

System design เน้น "ทำไม" มากกว่า "ยังไง" — เพราะ "ยังไง" หาเจอใน Stack Overflow แต่ "ทำไม" ต้องคิดเอง

---

2. ทำไม Engineer ต้องเรียน

ลองดูภาพรวมว่าตำแหน่งงานต่าง ๆ ใช้สกิล system design ต่างกันยังไง:

ระดับ	ประสบการณ์	งานหลัก	System design ต้องรู้แค่ไหน
Junior	0-2 ปี	เขียน code feature ที่ assigned	ไม่ต้องรู้เลย (focus เขียน code ให้ดี)
Mid	2-5 ปี	เขียน feature ใหญ่ขึ้น เลือก library	เริ่มเห็น trade-off — รู้พื้นฐาน
Senior	5-8 ปี	ออกแบบระบบใหม่ ตัดสินใจ architecture	ต้องคิดเป็น — ลูกทีมจะถาม
Staff/Principal	8+ ปี	นำทิศทาง technical ทั้งทีม/บริษัท	ต้องเชี่ยวชาญ — ทั้งหลายระบบเชื่อมกัน

ความจริงที่ engineer หลายคนพลาด

System design = สกิลที่ปลดล็อกตำแหน่ง senior — ถ้าเขียน code เก่งแต่คิดระบบไม่เป็น → ตัน mid forever

เหมือนช่างที่ "ตอกตะปูเก่งมาก" แต่ "วาดบ้านไม่เป็น" — ไม่มีใครจ้างเป็นสถาปนิก

---

3. ทำไม Interview ใช้ System Design

ใน Big Tech (Meta, Google, Amazon, Microsoft, Apple, Netflix, ฯลฯ) — interview process มักมี 3 ส่วน:

หมายเหตุชื่อกลุ่มบริษัท (ไม่ต้องจำ — ใช้แค่ "Big Tech" ก็พอ):

• FAANG / MAANG — คำเก่าของวงการ tech (Facebook/Meta + Amazon + Apple + Netflix + Google) ปัจจุบันคนสาย engineering/recruiting ใช้คำว่า "Big Tech" เป็นหลัก
• Magnificent 7 — เป็นคำของวงการตลาดหุ้น Wall Street ตั้งแต่ปี 2023 (Apple + Microsoft + Alphabet + Amazon + Nvidia + Meta + Tesla) ไม่ใช่ศัพท์ที่วิศวกรใช้กัน — ถ้าเจอในข่าวธุรกิจ ให้รู้ว่ามาจากนัก analyst ไม่ใช่ engineer

interview process ของ Big Tech มักมี 3 ส่วน:

1. Coding round (LeetCode style)     → วัด "แก้โจทย์เฉพาะ" ได้ไหม
2. System design round                → วัด "คิดระบบใหญ่" ได้ไหม
3. Behavioral round                   → วัด "สื่อสาร + culture fit"

จำนวน system design round ตามระดับ:

ระดับ	จำนวน rounds
ระดับกลาง (Mid / SDE II)	1
ระดับสูง (Senior / SDE III)	2
ระดับนำ (Staff+)	3+ (รวม architecture review)

หมายเหตุชื่อระดับ: SDE II/III เป็นชื่อตำแหน่งของ Amazon โดยเฉพาะ — บริษัทอื่นใช้ชื่อต่างกัน:

• Google: L3 (Entry) → L4 (Mid) → L5 (Senior) → L6 (Staff)
• Meta: E3 (Entry) → E4 (Mid) → E5 (Senior) → E6 (Staff)
• Microsoft: 59-60 (Mid) → 61-62 (Senior) → 63+ (Principal)

ในบทนี้เราใช้คำกลาง ๆ ว่า Mid / Senior / Staff+ แทน

ผ่าน system design = ปลดล็อก senior offer — เพราะบริษัทอยากได้คนที่ "ออกแบบเป็น" ไม่ใช่แค่ "เขียน code เป็น"

แต่อย่าลืม — เรียน system design ไม่ใช่เพื่อสอบ เพื่อให้คุณคิดเป็นในงานจริงด้วย

---

4. กระบวนการ System Design — ใช้ทั้งใน interview และงานจริง

ลองนึกภาพ — เวลาคุณจะออกแบบบ้าน ขั้นตอนจะเป็นยังไง?

1. คุยกับเจ้าของบ้าน    "อยากได้กี่ห้อง? งบเท่าไหร่? อยากเน้นอะไร?"
2. ประมาณการ            "ขนาดที่ดิน? ต้องสร้างกี่ชั้น?"
3. ร่าง layout            "วาดแปลนคร่าว ๆ — บ้านแบบไหน?"
4. ลงรายละเอียด          "ห้องครัวขนาดเท่าไหร่? วัสดุอะไร?"
5. เช็คจุดเสี่ยง          "ถ้าฝนหนักจะรั่วตรงไหน? ระบบไฟพอไหม?"
6. สรุป + ส่งงาน          "นี่คือบ้านที่ตอบโจทย์คุณ"

System design ใช้ขั้นตอนคล้ายกันเป๊ะ — แค่เปลี่ยน "บ้าน" เป็น "ระบบ software":

1. Understand requirements           [5-10 นาที]  ← คุยกับ user/interviewer
   - Functional: ทำอะไรได้บ้าง?
   - Non-functional: scale, latency, availability เท่าไหร่?

2. Estimate scale                     [3-5 นาที]   ← ประมาณการตัวเลข
   - DAU? Request/sec? Storage?

3. High-level design                  [10-15 นาที] ← ร่าง architecture
   - กล่อง + ลูกศร
   - บอก component ที่มี

4. Deep dive                          [15-20 นาที] ← ลงรายละเอียด
   - Component ใด component หนึ่ง
   - Data model, API, Storage

5. Address bottleneck                 [5-10 นาที]  ← เช็คจุดเสี่ยง
   - ส่วนไหนจะพังก่อน?
   - แก้ยังไง?

6. Wrap up                            [5 นาที]     ← สรุป
   - Summary
   - Future improvement
   - Q&A

อย่าพยายามจำขั้นตอนเป๊ะ — เข้าใจ logic ก็พอ. ใน interview จริงเขาให้เวลา 45-60 นาที — ใช้ block นี้คุมเวลาตัวเอง

---

5. RADIO Framework — กรอบคิดที่ใช้ตลอดเล่ม

หมายเหตุ: RADIO เป็นกรอบที่เล่มนี้ใช้สอน — ในตำราอื่น (เช่น Alex Xu, ByteByteGo) อาจเรียกชื่ออื่นหรือลำดับต่างกัน แต่ขั้นตอนใกล้เคียงกัน ใช้กรอบไหนก็ได้ที่จำง่ายและคุมเวลา interview ได้

มี mnemonic ง่าย ๆ ที่จำได้:

R — Requirements           "อยากได้อะไร?"
A — Architecture (high)    "ภาพรวมเป็นยังไง?"
D — Data model              "ข้อมูลเก็บยังไง?"
I — Interface (API)         "เรียกใช้ยังไง?"
O — Optimizations           "ทำให้ดีขึ้นยังไง?"

เปรียบเทียบกับการเขียน paper:

RADIO	เทียบกับ paper
Requirements	Abstract + Introduction (ทำอะไร)
Architecture	Methodology (วิธีการ)
Data	Data section (ข้อมูล)
Interface	API/Contract (สื่อสารกับ user)
Optimizations	Discussion + Future work (ทำให้ดีขึ้นต่อ)

เราจะใช้กรอบ RADIO นี้ใน worked examples ทุกตัวอย่างในบทที่ 5

---

6. R — Requirements (สำคัญที่สุด!)

กฎทอง #1: อย่าเริ่ม design ก่อนรู้ requirement — เหมือนสร้างบ้านก่อนถามเจ้าของบ้าน

Requirement แบ่งเป็น 2 ประเภท:

6.1 Functional Requirements — "ระบบทำอะไรได้?"

เน้นที่ feature — มองจากมุม user

ตัวอย่าง Twitter:
- User โพสต์ tweet ได้
- User follow คนอื่นได้
- User เห็น timeline (tweet ของคนที่ follow)
- User กด like / retweet ได้

ตัวอย่าง URL Shortener:
- รับ URL ยาว → คืน URL สั้น
- เปิด URL สั้น → redirect ไป URL ยาว
- นับจำนวนคลิก
- รองรับ custom alias (optional)

6.2 Non-Functional Requirements — "ระบบต้องดีแค่ไหน?"

คำย่อในส่วนนี้เป็นศัพท์ที่ใช้ตลอดทั้งเล่ม กางที่นี่ทีเดียว:

• DAU (ดี-เอ-ยู) = Daily Active Users — จำนวนผู้ใช้ที่ active ในวันหนึ่ง
• QPS (คิว-พี-เอส) = Queries Per Second — จำนวน request/query ต่อวินาที
• SLA (เอส-แอล-เอ) = Service Level Agreement — ข้อตกลงระดับบริการกับลูกค้า (เช่น "ระบบจะ up 99.9%")
• p95 (พี-เก้า-สิบห้า) = 95th percentile latency — ค่าเวลาที่ 95% ของ request เสร็จภายใน (อีก 5% ช้ากว่า)

ถ้าเจอคำอื่นไม่คุ้น เปิดดูตารางคำศัพท์ที่ ท้ายบท §23 ได้เลย

เน้นที่ คุณภาพ + ข้อจำกัด — มองจากมุม operations (ฝั่งดูแลระบบให้ทำงานได้จริงหลัง deploy):

Scale (ขนาด):
- DAU (Daily Active Users): 100K? 1M? 100M?
- Read/Write ratio: 100:1? 1:1?
- Geographic: เฉพาะไทย? หรือทั้งโลก?

Performance (ประสิทธิภาพ):
- Latency: p95 < 200ms?
  (อ่านว่า "95% ของ request เสร็จภายใน 200ms — อีก 5% ที่เหลือช้ากว่า 200ms")
  ตัวอย่าง: ถ้าวัด 1,000 request — 950 ตัวเสร็จในไม่เกิน 200ms อีก 50 ตัวช้ากว่านั้น
- Throughput: 10K req/sec? (จำนวนงานที่ระบบทำได้ต่อวินาที)

Availability (พร้อมใช้งาน):
- 99.9% (43 นาที downtime/เดือน)?
- 99.99% (4.3 นาที/เดือน)?

Consistency (ความถูกต้อง):
- Strong (ทุกคนเห็นข้อมูลเดียวกันทันที)?
- Eventual (ข้อมูล sync ภายในไม่กี่วินาที)?

Cost:
- งบเท่าไหร่?
- ยอมเสีย performance เพื่อลดค่าใช้จ่ายไหม?

6.3 คำถามที่ควรถาม Interviewer (หรือ stakeholder)

✅ "Scale ที่คาดไว้?"
✅ "Read/write ratio เป็นยังไง?"
✅ "Latency SLA?"
✅ "ต้อง support หลาย region ไหม?"
✅ "Eventual consistency รับได้ไหม?"
✅ "งบเป็น priority หรือ feature?"
✅ "Mobile + web หรือเฉพาะ web?"
✅ "Auth ใช้อะไร?"
✅ "Greenfield (สร้างใหม่จากศูนย์ ไม่มีของเก่า) หรือ migrate ของเก่า?"

อย่าเริ่ม design ก่อนถามให้ชัด — ถ้าออกแบบผิดทิศ = เสียเวลาเปล่า

---

7. การประมาณการคร่าว ๆ (Back-of-Envelope Estimation)

"Back-of-envelope estimation" เป็นสำนวนอเมริกัน — แปลตรง ๆ ว่า "คำนวณบนหลังซองจดหมาย" หมายถึง คำนวณเร็ว ๆ ด้วยตัวเลขกลม ๆ ไม่ต้องเป๊ะ ขอแค่ "เข้าใจขนาด" ว่าระบบจะใหญ่แค่ไหน เก็บข้อมูลกี่ TB ทำงานกี่ QPS

สมัยก่อนเวลาคนคุยกันแล้วต้องคำนวณเร็ว ๆ จะหยิบซองจดหมายที่มีอยู่ในมือมาเขียนเลข เลยกลายเป็นสำนวน

ตัวอย่าง walk-through สั้น ๆ

สมมติ interviewer ถามว่า "ระบบ chat มี 10M DAU แต่ละคนส่ง 50 ข้อความ/วัน ข้อความละ 100 bytes — ต้องใช้ storage เท่าไหร่ต่อปี?"

ขั้นที่ 1 — จำนวน message/วัน:    10M × 50 = 500M ข้อความ/วัน
ขั้นที่ 2 — storage/วัน:           500M × 100 bytes = 50 GB/วัน
ขั้นที่ 3 — storage/ปี:            50 GB × 365 ≈ 18 TB/ปี
ขั้นที่ 4 — write QPS เฉลี่ย:      500M ÷ 86,400 sec ≈ 5,800 writes/sec
ขั้นที่ 5 — peak QPS (5x):         5,800 × 5 ≈ 29,000 writes/sec

→ ได้ภาพแล้วว่า "18 TB/ปี + peak 29K writes/sec" — ตอนนี้ตัดสินใจ design ได้แล้วว่าใช้ DB เดียวพอไหม หรือต้อง shard

ทำไม peak = 5x avg? — เพราะ traffic จริงไม่กระจายเท่าทั้งวัน คนส่วนใหญ่ active ในช่วง 4-6 ชั่วโมงต่อวัน (เช้า, พักเที่ยง, ค่ำ) ถ้าเฉลี่ย 24 ชม. แต่ใช้จริง ~5 ชม. ก็ได้ peak ≈ 24/5 ≈ 5x เป็นรูล-ออฟ-ธัมบ์ที่ใช้กันใน interview (บางระบบ peak 3x บางระบบ 10x — 5x เป็นค่ากลาง)

7.1 ตัวเลขที่ engineer ทุกคนควรรู้

ไม่ต้องท่องตัวเลขในตาราง — ดูแค่ "ภาพรวม" ว่าอะไรเร็ว/ช้ากว่ากันมากแค่ไหน ประเด็นเดียวที่ต้องจำคือ: RAM เร็วกว่า disk มาก ๆ และ network ข้ามทวีปช้าที่สุด

หน่วยเวลาในตาราง (เล็ก → ใหญ่):

• ns = นาโนวินาที = 1 ใน 1,000,000,000 วินาที (เร็วสุด)
• μs = ไมโครวินาที = 1 ใน 1,000,000 วินาที (= 1,000 ns)
• ms = มิลลิวินาที = 1 ใน 1,000 วินาที (= 1,000 μs)

ลองดูตารางนี้ — ความเร็วของระบบต่าง ๆ (คอลัมน์ "เปรียบเทียบ" คือ "ถ้า L1 cache = 1 วินาที แล้วอย่างอื่นจะนานแค่ไหน" เพื่อให้เห็นภาพ):

Operation	เวลา	เปรียบเทียบ
L1 cache hit	0.5 ns	1 วินาที (อ้างอิง)
Branch mispredict	5 ns	10 วินาที
L2 cache hit	7 ns	14 วินาที
Mutex lock/unlock	100 ns	3 นาที
RAM access	100 ns	3 นาที
Send 1KB over 1Gbps	10 μs	5.5 ชั่วโมง
Read 1MB sequential from RAM	250 μs	6 วัน
SSD random read	16-150 μs	9 ชั่วโมง - 4 วัน
HDD seek	10 ms	7-8 เดือน
US→Europe→US network packet	150 ms	~9-10 ปี

ศัพท์ที่อาจไม่คุ้น:

• Branch mispredict = CPU พยายามทายล่วงหน้าว่า if-else จะไปทางไหน ถ้าทายผิด ต้องล้าง pipeline แล้วเริ่มใหม่
• L1/L2 cache = หน่วยความจำเล็ก ๆ ที่อยู่ใน CPU เร็วกว่า RAM มาก
• Mutex (mutual exclusion lock) = "กุญแจ" ที่ป้องกัน thread หลายตัวเข้าถึงข้อมูลพร้อมกัน

สิ่งที่ต้องจำ:

• RAM = เร็วกว่า disk เป็นพันเท่า
• Network ระหว่าง region = ช้ามาก (ใช้ replica ใกล้ user เสมอ)
• Cache hit = sub-millisecond
• DB query = หลาย ms ขึ้นไป

⚠️ Latency numbers ข้างบน = Jeff Dean's classic numbers (ปี 2012) — ตกรุ่นแล้ว ใช้เป็น "ลำดับขนาด" พอ ตัวเลขด้านล่างนี้เป็น order-of-magnitude estimate (ปี 2024+) สำหรับ hardware ยุคใหม่ — ตัวเลขเป๊ะขึ้นกับ vendor, queue depth, workload และ region pair กรุณา cross-check กับ datasheet/benchmark ก่อนใช้ใน design review

ตัวเลขสำคัญที่ engineer ปี 2026 ควรจำ (rounded):

• RAM access: ~100 ns (DDR4/DDR5 ใกล้เคียงกัน — DDR5 latency ดีกว่านิดเดียว throughput ดีกว่ามาก)
• NVMe SSD random read: ~10 μs (idle, QD=1)
• Intra-datacenter RTT: ~0.5 ms (same-AZ, private network)
• Cross-region RTT: 100-200 ms (ขึ้นกับระยะทาง — US↔SG ~180ms, US-east↔US-west ~70ms)

Operation	Modern 2024+ (ลำดับขนาด)	เก่า 2012
L1 cache	0.5-1 ns	0.5 ns
DDR5 RAM access (RAM รุ่นใหม่ปี 2024+)	~50-80 ns (ตัวเลข exact ต้องการ source — flagged 2026-06; DDR5 ลด latency จาก DDR4 ไม่มาก แต่ throughput สูงขึ้นเยอะ)	100 ns (DDR3)
HBM3 — RAM พิเศษสำหรับ GPU AI	order ของ ~100 ns (ตัวเลข exact ต้องการ vendor datasheet — flagged 2026-06)	— (ใหม่)
NVMe SSD random read (4KB) — SSD เร็วสุด เชื่อมผ่าน PCIe ตรง	10-30 μs (QD=1, idle) — ภายใต้ load จริง p99 อาจขึ้นไปถึง 50-200 μs (ต้องการ fio benchmark เพื่อยืนยัน — flagged 2026-06)	150 μs (SATA SSD)
HDD seek (จานหมุน)	10 ms (hot path สมัยใหม่แทบไม่ใช้แล้ว — เหลือ cold storage เช่น S3 Glacier)	10 ms
Same-AZ EC2 → EC2 (private backbone)	~50-100 μs (order of magnitude — ขึ้นกับ instance type)	0.5 ms
Same-region cross-AZ (private backbone)	1-3 ms	1 ms
Cross-region same cloud (private backbone)	เริ่มจาก ~30 ms (ใกล้กัน เช่น us-east-1 ↔ us-east-2) ถึง ~200+ ms (ไกล เช่น us-east-1 ↔ ap-southeast-1) (เช็คจริงด้วย AWS Latency Monitor / cloudpingtest)	150 ms (public internet)
Cross-region public internet (US↔EU)	80-150 ms	150 ms
Starlink LEO satellite (Low Earth Orbit — ดาวเทียมโคจรต่ำ ~550km)	~30-80 ms (ตัวเลขจาก third-party speedtest — ขึ้นกับ ground station ใกล้สุด — flagged 2026-06)	600 ms (geostationary 36,000km)

ทำไมต่าง (เชิงคุณภาพ): (1) NVMe เร็วกว่า SATA หลายเท่า, (2) DDR5 ปรับปรุง throughput เป็นหลัก ส่วน raw latency ดีขึ้นเล็กน้อย, (3) Cloud private backbone เร็วกว่า public internet ชัดเจน, (4) LEO satellite (Starlink, Amazon Kuiper) เร็วกว่า geostationary เยอะเพราะอยู่ใกล้โลกกว่ามาก

(last reviewed: 2026-06 — ตัวเลขในตารางนี้ยังไม่ได้ cross-check รายแถวกับ source ทางการ ถ้าจะใช้ใน design review ของจริง ให้เปิด datasheet / vendor benchmark ก่อน)

7.2 ตัวเลข storage

1 KB = 10^3 bytes
1 MB = 10^6
1 GB = 10^9
1 TB = 10^12
1 PB = 10^15

7.3 Pattern การคำนวณ

สูตรพื้นฐานที่ใช้บ่อย:

QPS (Queries Per Second):
   DAU × Actions per user per day / 86,400 sec = Average QPS
   Average × (3-5) = Peak QPS

Storage:
   Events per day × bytes per event = Storage per day
   × 365 × Retention years = Total storage

7.4 ตัวอย่างจริง — ประมาณการ Twitter

ข้อมูลที่ได้:
- 300M DAU
- โพสต์เฉลี่ย 2 tweet/user/day → 600M tweet/day
- ขนาด tweet ~200 bytes

→ Storage:
   600M × 200 bytes = 120 GB/day
   1 ปี = ~44 TB
   5 ปี = ~220 TB
   → ใหญ่เกินกว่า DB เดียวจะรับได้ → ต้อง shard

→ Write QPS:
   600M / 86,400 ≈ 7,000 tweets/sec (เฉลี่ย)
   Peak = ~5x = 35,000 tweets/sec

→ Read QPS (timeline):
   300M user × 100 tweet view/day = 30B reads/day
   เฉลี่ย: ~350K reads/sec
   Peak: ~1.5M reads/sec

→ Read/Write ratio = 1.5M / 35K = ~40:1
   → Read-heavy! ต้องใช้ caching เยอะ

Insight ที่ได้: ตัวเลขเหล่านี้ "บอก" เราว่าต้องออกแบบยังไง — ไม่ใช่เรา "เดา" — เป็นการ "วัด"

---

8. A — Architecture (High-Level)

ภาพรวมของ component ที่เจอบ่อยใน modern system:

Pattern ที่ใช้บ่อย — Web App ทั่วไป

กฎสำคัญ — เริ่มเรียบง่ายก่อน

อย่าใส่ component ทุกตัวจาก start — ใส่เฉพาะที่ requirement ต้องการ

ตัวอย่าง — สำหรับ URL shortener เล็ก ๆ:

ระยะที่ 1 (MVP):     [Client] → [Server + DB เดียว]
ระยะที่ 2 (1K users): + [Cache (Redis)]
ระยะที่ 3 (100K users): + [LB] + [Multiple servers]
ระยะที่ 4 (1M users): + [CDN] + [Read replicas]
ระยะที่ 5 (10M users): + [Sharding] + [Queue + workers]

→ Add complexity เมื่อ "ต้อง" ไม่ใช่ "เพราะดูดี"

---

9. D — Data Model

9.1 Step 1: ระบุ Entity

Entity = "สิ่ง" ที่ระบบจัดการ — ส่วนใหญ่เป็น noun (คำนาม)

สำหรับ Twitter:
- User (id, name, email, created_at)
- Tweet (id, user_id, text, created_at)
- Follow (follower_id, followee_id, created_at)
- Like (user_id, tweet_id, created_at)

Relationships (ความสัมพันธ์):
- User 1:N Tweet      (1 user มีหลาย tweet)
- User M:N User        (follow — many-to-many)
- User M:N Tweet       (like — many-to-many)

9.2 Step 2: Schema (rough)

-- User table
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Tweet table
CREATE TABLE tweets (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL REFERENCES users(id),
    text VARCHAR(280) NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Index สำคัญ — ค้น tweet ของ user เรียงตามเวลา
CREATE INDEX idx_tweets_user_created ON tweets(user_id, created_at DESC);

-- Follow table — composite primary key
CREATE TABLE follows (
    follower_id BIGINT REFERENCES users(id),
    followee_id BIGINT REFERENCES users(id),
    created_at TIMESTAMPTZ DEFAULT NOW(),
    PRIMARY KEY (follower_id, followee_id)
);

ไม่ต้อง schema เป๊ะ ใน interview — แค่แสดงว่าคุณคิดเรื่อง entity, relationship, index ได้

9.3 Step 3: SQL vs NoSQL — เลือกยังไง?

นี่คือคำถามที่เจอบ่อยที่สุดในการสัมภาษณ์ — มี decision tree ง่าย ๆ:

ประเภท	เด่นที่	ใช้เมื่อ
SQL (Postgres, MySQL)	ACID, JOIN, mature	Default — เว้นแต่มีเหตุชัดว่าไม่ใช่
NoSQL Document (MongoDB)	Schema flex, nested	Schema-less, read-heavy
NoSQL Key-Value (Redis, DynamoDB)	⚡ Ultra fast	Cache, session, simple K-V
NoSQL Wide-column (Cassandra)	Write-heavy, massive scale	IoT, log, metrics
Search (Elasticsearch)	Full-text, fuzzy match	Search engine
Graph (Neo4j)	Relationship traversal	Social network, recommendation
Time-series (TimescaleDB)	Time-indexed	Metrics, monitoring
Analytics (ClickHouse, BigQuery)	OLAP queries	Reporting, BI
Vector (pgvector, Pinecone)	Similarity search	AI embeddings, RAG

9.4 กฎทอง — "Pick boring technology"

Dan McKinley (อดีต CTO Etsy) บอกไว้ — "เลือกของน่าเบื่อก่อน"

Boring technology = Postgres
Exciting technology = MongoDB ใหม่ที่ launch เมื่อปีที่แล้ว

Postgres ทำได้:
- ACID transactions
- JSONB (เก็บ document-style)
- Full-text search (tsvector)
- pgvector (AI embeddings)
- TimescaleDB (extension สำหรับ time-series)
- PostGIS (geo data)

→ ทำได้ ~99% ของ use case ก่อนต้องเปลี่ยน DB

ดู Database book สำหรับรายละเอียดลึก

---

10. I — Interface (API)

API = "หน้าบ้าน" ที่ client เรียกใช้ — มี 3 style หลัก:

10.1 REST — Default ส่วนใหญ่

POST   /api/users               — สร้าง user
GET    /api/users/{id}          — อ่าน user
PATCH  /api/users/{id}          — อัพเดตบางส่วน
DELETE /api/users/{id}          — ลบ

POST   /api/tweets              — โพสต์ tweet
GET    /api/tweets/{id}         — ดู tweet
GET    /api/users/{id}/tweets   — tweet ของ user คนนี้

POST   /api/follows             — follow คน
DELETE /api/follows/{id}        — unfollow

GET    /api/feed                — timeline ของ user ที่ login

เด่นที่: ง่าย, ทุก language รองรับ, cache ง่าย (HTTP cache)

ดู API Design book ละเอียด

10.2 GraphQL — ดึงข้อมูลครั้งเดียว

query Feed {
    me {
        timeline(limit: 20) {
            id
            text
            createdAt
            author { id name }
            likes
            comments {
                id
                text
                author { id name }
            }
        }
    }
}

เด่นที่: client ขอเฉพาะ field ที่ต้องการ — ลด over-fetching

ใช้เมื่อ: mobile + desktop ต้องการ data ต่างกัน, มี multiple data source

10.3 gRPC — internal service-to-service

service TweetService {
    rpc PostTweet(PostTweetRequest) returns (Tweet);
    rpc GetTweet(GetTweetRequest) returns (Tweet);
    rpc StreamUserTweets(UserRequest) returns (stream Tweet);
}

เด่นที่: binary protocol = เล็กกว่า JSON, type-safe, streaming

ใช้เมื่อ: service-to-service ภายใน, microservice, low-latency

---

11. O — Optimizations + Bottlenecks

11.1 หา Bottleneck — ถามตัวเองว่า

สำหรับทุก component ในระบบ ถาม:
1. "ถ้า traffic 10x ขึ้น — component นี้รับไหวไหม?"
2. "ถ้าพังขึ้นมา — กระทบส่วนไหนบ้าง?"
3. "ค่าใช้จ่ายต่อ user คือเท่าไหร่?"

11.2 Bottleneck ที่เจอบ่อย + ทางแก้

Bottleneck	สัญญาณ	วิธีแก้
DB overload	Query slow, CPU 100%	Read replicas, Caching, Sharding, Denormalize
API slow	High p99 latency	Caching (CDN, Redis), Async processing, Pagination, DB indexes
Hot path compute	Repeated expensive calc	Pre-compute, Materialized view, Background job
Single point of failure	1 service down → ทั้งระบบล่ม	Multi-region, Failover, Circuit breaker
Network latency	User ไกล data center	CDN, Geo DNS, Edge compute

11.3 ตัวอย่าง — Twitter timeline ช้า

ปัญหา:
- User เปิด timeline
- Server query DB ทุกคนที่ user follow
- JOIN กับ tweet table
- Sort by time
- Latency 3 วินาที — ช้ามาก

ทางแก้ที่เจอจริงใน Twitter:
1. Pre-compute timeline ตอน tweet ถูกโพสต์ (fanout-on-write — push timeline ไปเก็บที่ผู้ติดตามทุกคนตอนโพสต์: เขียนหนัก-อ่านเบา)
2. เก็บใน Redis cache (timeline:user_id → list of tweet IDs)
3. Read = O(1) lookup ใน Redis
4. Latency ลดเหลือ < 50ms

เสริม — fanout-on-write vs fanout-on-read:

• fanout-on-write = push timeline ไปทุก follower ตอนโพสต์ (write หนัก, read เบา) — ดีกับ user ทั่วไป
• fanout-on-read = ตอน follower เปิด timeline ค่อย query จาก author ทีหลัง (write เบา, read หนัก) — ดีกับ celebrity ที่มี follower เป็นล้าน เพราะถ้า fanout-on-write ตอนโพสต์ครั้งเดียวต้องเขียนเป็นล้าน row
• Twitter ใช้ hybrid — user ทั่วไปใช้ fanout-on-write, celebrity (follower เยอะมาก) ใช้ fanout-on-read แล้ว merge ตอนอ่าน

---

12. Trade-offs ที่ต้อง discuss ในทุก interview

System design = trade-off — ไม่มีคำตอบ "ถูก" คำตอบเดียว

12.1 CAP Theorem (และ PACELC ที่ขยายต่อ)

อย่าท่องว่า "เลือก 2 ใน 3" — เป็นการสรุปแบบเก่าและเข้าใจผิดได้ง่าย Brewer (ผู้คิด CAP) เองออกมาแก้ภายหลัง: CAP บอกแค่ว่า "ตอนเกิด partition" เท่านั้นที่ต้องเลือกระหว่าง C กับ A — ตอนระบบปกติไม่ต้องเลือกอะไรเลย

CAP — 3 properties:
- Consistency: ทุก read ได้ข้อมูลล่าสุด
- Availability: ทุก request ตอบสำเร็จ
- Partition tolerance: ทำงานได้แม้ network แยก

ในระบบ distributed จริง partition เกิดได้เสมอ → P ต้องมี
→ คำถามจริง ๆ คือ: "ตอน partition เกิด เลือก C หรือ A?"

PACELC (Abadi, 2010) — extend CAP ให้ครอบคลุมตอน "ไม่มี partition" ด้วย:

PACELC: ถ้า Partition (P) เกิด → เลือก A vs C
       Else (E, ระบบปกติ)      → เลือก L (Latency) vs C (Consistency)

Database	PACELC	ความหมาย
Cassandra (default)	PA/EL	partition: เลือก A, ปกติ: เลือก low latency
DynamoDB (eventual)	PA/EL	คล้าย Cassandra
MongoDB (default)	PA/EC	partition: เลือก A, ปกติ: เลือก consistency
HBase	PC/EC	เลือก consistency ทั้งสองกรณี
Spanner	PC/EC	strong consistency (TrueTime) แลกกับ latency สูงกว่า

ทำไม PACELC สำคัญ: ในระบบสมัยใหม่ partition เกิดน้อย แต่ trade-off latency-vs-consistency เกิดทุก request — PACELC ทำให้เห็นภาพรวมจริงกว่า CAP เพียว ๆ

(อ่านต่อ: Daniel Abadi, "Consistency Tradeoffs in Modern Distributed Database System Design" 2012)

ตัวอย่างให้เห็นภาพ — ตู้ ATM 2 ที่ แล้วเน็ตระหว่างกันขาด:

สมมติบัญชีเดียวมีเงิน 1,000 บาท ลูกค้าไปกดที่ ATM 2 เครื่องพร้อมกัน แต่สาย network ระหว่างเครื่องขาด (partition) — แต่ละเครื่องไม่รู้ว่าอีกเครื่องทำอะไร เลยต้องเลือก:

• เลือก A (Availability): ให้กดเงินได้ทั้งคู่เลย → ลูกค้าแฮปปี้ ไม่มี error แต่เสี่ยง "กดเกินยอด" (กดได้ 1,000 + 1,000 = 2,000 ทั้งที่มีแค่ 1,000)
• เลือก C (Consistency): ล็อกไว้ ห้ามกดจนกว่าเน็ตจะกลับมาคุยกันได้ → เงินไม่มีทางเกิน แต่ลูกค้ากดไม่ได้ (เจอ error)

→ ธนาคารจริงเลือก C (ยอมให้กดไม่ได้ ดีกว่าเงินหาย) ส่วน social feed มักเลือก A (เห็นโพสต์ช้าไปหน่อยไม่เป็นไร ขอให้ใช้ได้)

ดู Distributed Systems book ละเอียด

12.2 รายการ trade-off ที่ต้องรู้

Trade-off	Option A	Option B
CAP	Consistency	Availability
Consistency	Strong (immediate)	Eventual (catch up)
Storage	SQL (ACID, JOIN)	NoSQL (flex, scale)
Scaling	Vertical (simple)	Horizontal (unlimited)
Notification	Push (real-time, expensive)	Pull (delayed, cheap)
State	Stateful (simple)	Stateless (scale)
Architecture	Monolith (simple)	Microservices (independent)
Communication	Sync (immediate)	Async (decoupled)
API	REST (simple)	GraphQL (flexible) / gRPC (fast)
Cache strategy	Write-through (slow write, fresh)	Write-back (fast write, risk loss)

กฎทอง interview: ทุกการตัดสินใจ — บอกทั้ง "เลือกอะไร" และ "เพราะอะไร" + "alternative คืออะไร"

---

13. Common Mistakes (สิ่งที่ทำให้ interview พลาด)

13.1 ❌ "Code first" — เริ่ม code ก่อนเข้าใจปัญหา

สถานการณ์:
Interviewer: "Design Twitter"
You: "OK งั้นใช้ Postgres + Redis + Kafka..."
   (เริ่มลง detail ทันที โดยไม่ถาม requirement)

ปัญหา:
- ไม่รู้ scale ที่ต้อง design (1K user หรือ 1B?)
- ไม่รู้ feature ที่ต้องมี
- ออกแบบไป "อาจ" ผิดทิศ

สถานการณ์ที่ถูก:
You: "ก่อนเริ่ม ขอเข้าใจเพิ่ม:
       - DAU เท่าไหร่?
       - Read/write ratio?
       - Feature core vs nice-to-have?
       - Latency SLA?
       - Multi-region?"

13.2 ❌ Over-engineer — ใส่ของไม่จำเป็น

สถานการณ์:
"Design URL shortener"
You: "ใช้ Kafka, Cassandra, Kubernetes, microservices, Istio service mesh..."

ปัญหา:
- URL shortener เล็กมาก — ใช้ Postgres + Redis พอ
- ใส่ของเยอะ = แสดงว่าไม่เข้าใจ "match complexity to need"

กฎ: Complexity ของ solution ควร match กับ complexity ของ problem — ไม่ใช่โชว์ของเยอะ

13.3 ❌ One-way conversation — ไม่ฟัง interviewer

Interview = collaboration ไม่ใช่ presentation

❌ พูดคนเดียว 30 นาที ไม่ pause
✅ "make sense?", "thoughts?", "any specific area to focus on?"
✅ Listen to hint — ถ้า interviewer ถาม "what about X?" = X สำคัญ

13.4 ❌ Miss requirements — ลืม feature ที่ถามตอนต้น

Interviewer (ตอนต้น): "ระบบต้อง support real-time"
You (ตอนกลาง): "ใช้ batch process ทุก 5 นาที"

→ ลืม requirement = น่ากลัวกว่าผิด design

วิธีกัน:
- เขียน requirement บน whiteboard
- ดูซ้ำตอน design

13.5 ❌ No trade-off discussion — บอกแค่ "ใช้ X"

❌ "ใช้ Cassandra"
✅ "ใช้ Cassandra เพราะ write-heavy + eventual consistency รับได้
    Alternative: DynamoDB (managed, แพงกว่า) หรือ ScyllaDB (เร็วกว่า)
    เลือก Cassandra เพราะ team รู้แล้ว + open source"

13.6 ❌ Hand-wave — พูดลอย ๆ ไม่เจาะ

❌ "It scales horizontally"
   → How? Sharded by what? Hot key อะไร?

✅ "Shard ตาม user_id ด้วย consistent hashing
    Hot key (celebrity) แยกออก dedicated cluster
    Resharding ด้วย virtual nodes"

13.7 ❌ Get stuck — ลงรายละเอียดบาง section ตัน

❌ 30 นาทีกับ schema design แล้วเวลาหมด ไม่ได้คุย architecture
✅ Time-box: ถ้า 5 นาทีแล้วยังตัน → "I'd use X, can refine later" → move on

---

14. Communication Tips

system design interview วัด "วิธีคิด" มากกว่าคำตอบสุดท้าย — การสื่อสารจึงสำคัญพอ ๆ กับเนื้อหา คิดดัง ๆ ให้ interviewer ตามทัน, วาดและตั้งชื่อทุกกล่องให้ชัด, หยุดขอ feedback เป็นระยะ และยอมรับ trade-off ทุกการตัดสินใจ เช็กลิสต์ "ควร/ไม่ควร" นี้ช่วยให้นำเสนอได้ดีขึ้น:

✅ Think aloud — พูดทุกอย่างที่คิด
✅ "Let me explain my thinking..."
✅ Draw + label clearly — แต่ละกล่องมีชื่อ
✅ Number components (1, 2, 3)
✅ Pause for feedback ทุก ~5 นาที
✅ Acknowledge trade-offs ทุก decision
✅ Use real examples ("like Instagram does...")

❌ Long silence (น่ากลัว)
❌ Skip explanation (interviewer งง)
❌ Use jargon ไม่อธิบาย
❌ Defensive เมื่อ feedback

---

15. Tools for Practice

15.1 Draw architecture

• Excalidraw ⭐ — ฟรี, ง่าย, ใช้ใน interview จริง
• draw.io — feature เยอะ
• Lucidchart — มี paid version
• Whimsical — modern, dynamic

15.2 Interview practice

• pramp.com — peer-to-peer ฟรี
• interviewing.io — paid, real interviewer
• meetapro — alternative
• Friend mock interview — ดีสุด

15.3 Real systems to study

• High Scalability — blog เก่าแต่ classic
• Engineering blogs: Uber, Stripe, Netflix, Discord, Cloudflare, Meta
• ByteByteGo (Alex Xu) — short + visual

---

16. Cheat Sheet — Quick Reference

16.1 Capacity Numbers ที่ต้องจำ

1 second  = 1,000 ms = 10^9 ns
1 day     = 86,400 sec (~10^5)
1 year    = 365 days

1 GB      = 10^9 bytes
1 TB      = 10^12 bytes
1 PB      = 10^15 bytes

Common scales:
- 1M users × 10 actions/day = 10M events/day
- 10M events/day ÷ 86,400 = 116 events/sec (avg)
- Peak ≈ 5x avg = 580 events/sec

16.2 Storage Estimate per Year

User profile (1 KB) × 10M users = 10 GB
Tweet (300 bytes) × 1B tweets/year = 300 GB
Image (500 KB) × 100M uploads/year = 50 TB
Video (50 MB) × 10M uploads/year = 500 TB

16.3 Latency Targets ทั่วไป

P95 latency goals:
- API simple call: 50ms
- API complex (multiple DB):  200ms
- DB query: < 50ms
- Cache hit: < 5ms
- Acceptable user perception: 100ms
- Frustration starts: > 1 sec

16.4 QPS อ้างอิงของระบบจริง

⚠️ ตัวเลขด้านล่างคือ public/historical figures ที่อ้างถึงได้ — ตัวเลข real-time ปี 2026 บริษัทไม่เปิดเผย และบางตัวเลขเก่ามาก (โดยเฉพาะ Twitter pre-2022 ก่อนเปลี่ยนเจ้าของ + ตัด infra) ใช้เพื่อให้เห็น ลำดับขนาด เท่านั้น ไม่ใช่ตัวเลข current

Google search:    ~100K QPS sustained (ITU 2024 est.)
Twitter writes:   143K tweets/sec peak (2013 Aug 2, "Castle in the Sky" — BBC News, Twitter blog)
                  ⚠️ ตัวเลขนี้มาจากยุค Twitter Inc. ก่อนปี 2022 — หลังเปลี่ยนเจ้าของ Twitter/X ตัด datacenter
                     และลดความ distributed ลง architecture ปัจจุบันต่างจากตอนนั้นมาก
                  ~6K-10K sustained (Twitter API docs, 2020)
YouTube uploads:  500 hours of video/min (Google I/O 2019)
Amazon orders:    600+ items/sec peak (Prime Day 2023, Amazon press)
Stripe payments:  ~13K req/sec peak Black Friday (Stripe Press, 2021)
WhatsApp msgs:    100B msgs/day (Meta earnings, 2020) ≈ ~1.2M/sec sustained
Cloudflare DNS:   1.1.1.1 — 1.6T queries/day (Cloudflare radar, 2023) ≈ ~18M QPS sustained
TikTok DAU:       1.5B (Bytedance 2024 report)

ใช้ตัวเลขนี้เป็น "reference" — ระบบที่ design ของคุณ proportional ขนาดไหน? Numbers ปี 2026 อาจมากกว่าเดิม 2-5x (growth + AI workload)

---

17. Resources — เรียนต่อจากที่ไหน

17.1 หนังสือ

• "Designing Data-Intensive Applications" (Kleppmann) ⭐⭐⭐
  → "DDIA" — bible ของ engineer ทุกคน. อ่านครั้งแรกจะหนัก ค่อย ๆ อ่าน
• "System Design Interview Vol 1 + 2" (Alex Xu)
  → Practical examples, เหมาะกับเตรียม interview
• "Building Microservices" (Sam Newman)
  → Architecture-level

17.2 Video

• ByteByteGo (Alex Xu) — short + visual, animation ดี
• System Design Interview — focus interview
• Gaurav Sen — deep dives, technical
• Tech Dummies — varied topics

17.3 Real-world Engineering Blogs

- High Scalability (blog)
- Uber Engineering
- Netflix Tech Blog
- Stripe blog
- Cloudflare blog
- Meta Engineering
- Discord Engineering
- Slack Engineering
- Pinterest Engineering
- Airbnb Engineering

17.4 Framework / Standards

• AWS Well-Architected Framework — pillars ของ cloud architecture
• Google SRE book (ฟรี online) — reliability engineering
• Microsoft Azure Architecture Center — patterns

---

18. Mindset Shift — จาก "Code" สู่ "System"

ลองเทียบความคิดของ junior กับ senior ในเรื่องเดียวกัน:

Junior dev

• "How do I implement this feature?"
• "What's the best algorithm?"
• "How do I make this fast?"

Senior dev

• "What's the problem we're solving?"
• "What are the constraints?"
• "What's the trade-off?"
• "How does this fail?"
• "How does this scale?"
• "What's the cost?"
• "How do I monitor it?"
• "What's the rollback plan?"
• "What's the SLA?"

Shift จาก "code-level" → "system-level" thinking — นี่คือสิ่งที่ system design สอน

---

19. Real-world Process (เกิน Interview)

ใน interview เวลา 45 นาที — ในงานจริงทำกันยังไง?

Week 1: Discovery
- คุยกับ stakeholders (PM, business, users)
- เข้าใจ domain — ขอบเขตของปัญหา
- List requirement (functional + non-functional)
- ระบุ constraints (budget, timeline, compliance)

Week 2: High-level
- Whiteboard session กับทีม
- ร่าง 2-3 alternative architecture
- Trade-off analysis เปรียบเทียบ

Week 3: Detailed
- API design
- Data model
- Component breakdown
- เลือก tech stack

Week 4: Review
- Architecture review meeting (กับ senior eng)
- Peer review
- Stakeholder approval

Week 5+: Implementation
- แบ่ง milestone
- Design "ต่อ" ระหว่าง build (ปรับตามที่เรียนรู้)
- Iterate

งานจริง = iterative + collaborative — ไม่ใช่ออกแบบครั้งเดียวจบ

---

20. Document = สำคัญ — ADR

การตัดสินใจด้านสถาปัตยกรรมที่ดีอาจดูแปลกในอีก 6 เดือน ถ้าไม่มีบันทึกว่า "ทำไมตอนนั้นเลือกแบบนี้" — ADR (Architecture Decision Record) คือเอกสารสั้น ๆ ที่จดบริบท การตัดสินใจ ผลที่ตามมา และทางเลือกที่ปฏิเสธ ทำให้ทีมและคนใหม่เข้าใจเหตุผลย้อนหลังได้ เทมเพลตด้านล่างใช้ได้เลย:

ADR (Architecture Decision Record) = บันทึก "ทำไมเราเลือก X" ที่ track ได้

# ADR-001: Use Postgres over MongoDB

## Context (สถานการณ์)
ต้องเลือก primary database สำหรับ user, transaction, order — 
read/write ~10:1, ต้อง ACID

## Decision (ตัดสินใจ)
ใช้ Postgres 16

## Consequences (ผลที่ตามมา)
+ ACID transactions
+ Strong consistency
+ SQL ที่ทีมรู้แล้ว
+ JSONB สำหรับ flex schema
- Horizontal scaling ยากกว่า MongoDB
- Schema migration rigid กว่า

## Alternatives Considered (ทางเลือกอื่น)
- MongoDB: ปฏิเสธเพราะต้อง JOIN + transaction
- MySQL: ปฏิเสธเพราะ Postgres JSON ดีกว่า
- CockroachDB: คุย — ถ้า scale หนัก → consider

ประโยชน์: 6 เดือนผ่านไป มีคนถาม "ทำไมเลือก X?" — มี answer ที่ track ได้
Onboarding engineer ใหม่ก็ใช้

---

21. Checkpoint — ฝึกทำเอง

🛠️ Checkpoint 0.1 — Practice Estimation
เลือก app ที่ใช้ทุกวัน (Instagram, Spotify, YouTube) แล้วประมาณ:

• DAU
• Storage requirements (per day, per year)
• Read/write QPS
• Bandwidth

🛠️ Checkpoint 0.2 — Identify Components
ลิสต์ component หลัก ของ:

• WhatsApp
• Uber
• Amazon
• Spotify
• Discord

🛠️ Checkpoint 0.3 — Read Engineering Blog
เลือก 1 อ่าน:

• "How Discord Indexes Billions of Messages"
• "How Stripe handles thousands of transactions"
• "How Uber Built Schemaless"

สรุปสั้น ๆ:

• ปัญหาคืออะไร?
• Architecture ใช้อะไร?
• Trade-off ที่ทำคืออะไร?

🛠️ Checkpoint 0.4 — Draw Architecture
เปิด Excalidraw วาด:

• Personal blog site (simple)
• E-commerce site (medium)
• Real-time chat (complex)

🛠️ Checkpoint 0.5 — Watch ByteByteGo
ดู 3 videos:

• "How Netflix delivers 100s of TB per day"
• "How to design Twitter"
• "How payment systems work"

จดบันทึก: pattern ไหนใช้ซ้ำ?

---

22. สรุปบท

ทบทวนสิ่งสำคัญที่ได้:

✅ System design = วิธีคิดเรื่องระบบใหญ่ — ไม่ใช่ code
✅ Process: Requirements → Estimate → High-level → Deep dive → Bottleneck → Wrap up
✅ RADIO framework: Requirements, Architecture, Data, Interface, Optimizations
✅ อย่าเริ่ม design ก่อนถาม requirement ให้ชัด
✅ Estimate scale — DAU × actions = QPS, peak ≈ 5x avg
✅ Common components: CDN, LB, API server, cache, DB, queue, workers
✅ Trade-offs always — ไม่มี single "right answer"
✅ Avoid mistakes: jump to code, over-engineer, miss requirement, hand-wave
✅ Communicate: think aloud, draw, pause for feedback
✅ Read: DDIA (Kleppmann), Alex Xu books, engineering blogs

---

23. คำศัพท์ที่จะเจอตลอดเล่ม

คำศัพท์	ความหมาย
DAU	Daily Active Users — จำนวน user ที่ active ในวันหนึ่ง
QPS	Queries Per Second — request ต่อวินาที
Throughput	จำนวนงานที่ระบบทำได้ต่อหน่วยเวลา
Latency	เวลาที่ใช้ตอบ 1 request (ms)
p50/p95/p99	percentile latency — p99 = 99% ของ request เร็วกว่านี้
SLA	Service Level Agreement — สัญญากับ customer
SLO	Service Level Objective — เป้าหมายภายใน
SLI	Service Level Indicator — ตัวชี้วัด
CDN	Content Delivery Network — cache ที่ edge ใกล้ user
LB	Load Balancer — กระจาย traffic
Replica	DB สำเนาที่ sync จาก primary
Sharding	แบ่ง data ไป DB หลายตัว
Partitioning	คล้าย sharding — แบ่งภายใน DB เดียว
Stateless	server ไม่จำ state — scale ง่าย
Stateful	server จำ state ของ session — scale ยาก
CAP	Consistency, Availability, Partition tolerance — เลือก 2 ใน 3
ACID	Atomicity, Consistency, Isolation, Durability (transaction property)
Idempotent	ทำ N ครั้ง = ทำ 1 ครั้ง (เช่น DELETE)
Eventual consistency	sync ภายในเวลาสั้น ๆ (ไม่ทันที)
Strong consistency	read ได้ data ล่าสุดทันที
Fanout	ส่งข้อความถึง subscribers หลายคน
Hot key	key ที่ถูก access บ่อยมาก

---

บทถัดไป → Scalability Patterns

---

🔤 Glossary · 📋 Style guide · 📅 last_verified: 2026-06-03