Skip to content

System Design

ส่วนหนึ่งของ Beginner Book | เสริมจาก Distributed Systems

⚠️ ถ้าคุณเพิ่งเริ่มเขียนโปรแกรมจริง ๆ — เล่มนี้ยังไม่ใช่ที่ของคุณ (ตอนนี้)

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

เช็คตัวเอง — พร้อมอ่านเล่มนี้หรือยัง? (ถ้าตอบ "ใช่" ทุกข้อ → พร้อม)

  • ☐ เคยทำ CRUD app (Create-Read-Update-Delete) จบ 1 ตัว
  • ☐ รู้ว่า HTTP / REST API ทำงานยังไง (GET/POST, status code, JSON body)
  • ☐ รู้ว่า database คืออะไร — เขียน SQL query พื้นฐานได้ (SELECT/INSERT/UPDATE)
  • ☐ เข้าใจคำว่า client / server / port / IP
  • ☐ เคย deploy app ขึ้น server / cloud อย่างน้อย 1 ครั้ง (heroku, render, AWS, ฯลฯ)

ถ้าตอบ "ไม่" ข้อใดข้อหนึ่ง → กลับไปอ่าน Java + Spring Boot ก่อน

ศัพท์ฝรั่งในเล่มนี้เยอะมาก เรากางคำให้ตอนโผล่ครั้งแรก แต่ถ้ายังไม่คุ้นพื้นฐาน จะตามไม่ทัน

หนังสือเล่มนี้พาคุณไปถึงไหน

อ่านจบ + ทำ checkpoint หมด คุณจะ:

  • คิดเป็น "system" — ไม่ใช่แค่ code
  • ออกแบบระบบที่ scale ได้ + reliable
  • เข้าใจ trade-off ของ pattern (caching, sharding, queue)
  • สอบ system design interview ได้
  • ออกแบบ + present idea ในงานจริง

หนังสือนี้ออกแบบมาให้ใคร

✅ Mid-level engineer ที่อยากขึ้น senior
✅ คนเตรียมสอบ system design interview (Big Tech — เช่น Meta, Google, Amazon, Microsoft, Apple, Netflix)
✅ Tech lead ที่ออกแบบระบบใหม่
✅ Backend developer ที่อยากเห็นภาพใหญ่

หมายเหตุเรื่อง interview rubric: เกณฑ์การวัดแบบ "Strong Hire / Hire / Lean Hire / No Hire" และโครงสร้าง system design round 45-60 นาทีในเล่มนี้ เป็น มาตรฐานของ US Big Tech (Meta, Google, Amazon, ฯลฯ) ตลาดงานไทย/อาเซียน + บริษัทเล็ก-กลาง อาจไม่มี round นี้ หรือมีแบบไม่เป็นทางการ — ใช้กรอบในเล่มเป็น "วิธีคิด" ได้ แต่อย่าคาดหวังว่า interviewer ไทยจะ score แบบเป๊ะ ๆ ตามนี้

❌ Junior developer (ควรเขียน code คล่องก่อน)
❌ Distributed systems researcher (เล่มนี้ practical, ไม่ใช่ theoretical)

ปรัชญาของเล่มนี้

เล่มนี้ไม่ได้สอนให้ท่อง "คำตอบที่ถูก" เพราะ system design ไม่มีคำตอบเดียว — มีแต่ trade-off ที่เหมาะกับบริบทต่างกัน เป้าหมายคือฝึก "วิธีคิด" ผ่าน pattern, ตัวอย่างจริง และการลงมือออกแบบเอง:

"system design ไม่มีคำตอบที่ 'ถูก' — มีแต่ 'ได้อย่างเสียอย่าง' (trade-off)"
   (อังกฤษ: "There are no right answers in system design — only trade-offs")

แทนที่จะให้คำตอบที่ถูก:
- สอนวิธี "คิด"
- เสนอ pattern + trade-off
- ใช้ตัวอย่างจริง (Instagram, Uber, Stripe)
- ลองเอง — design 5 systems ในเล่ม

Pareto principle (กฎ 80/20): 80% ของผลลัพธ์ มาจาก 20% ของความพยายาม — เล่มนี้เน้น pattern 20% ที่ใช้ใน 80% ของระบบจริง ไม่ครอบคลุมทุก edge case

บทเรียน

#บทสอนอะไร
0System Design Mindsetกระบวนการ, RADIO framework, requirements
1Scalability Patternsvertical/horizontal, load balancing, stateless
2Data Layer (Storage + Cache)SQL/NoSQL choice, sharding, replication, caching
3Communication Patternssync/async, queue, pub-sub, event-driven
4Reliability + Resilienceretry, circuit breaker, timeout, idempotency, SLA
5Worked ExamplesURL shortener, Twitter, Uber, Netflix, chat
6Interview Strategyhow to approach, scoring, pitfalls, mock interview

วิธีอ่านที่แนะนำ

  1. อ่านแล้ววาดทุกบท — กระดาษ + ปากกา หรือ Excalidraw
  2. ทำ Worked Examples ด้วยตัวเอง ก่อนอ่านเฉลย
  3. พูดออกเสียง — interview = พูด ไม่ใช่ writing
  4. อย่ามองหา "right answer" — มอง trade-off

Resources

แหล่งเรียนต่อที่แนะนำหลังจบเล่มนี้ — มีทั้งหนังสือคลาสสิก (DDIA, Alex Xu), ช่อง/newsletter และ engineering blog ของบริษัทจริงที่เล่าสถาปัตยกรรมของระบบสเกลใหญ่:

  • "Designing Data-Intensive Applications" (Kleppmann) — bible
  • "System Design Interview" (Alex Xu) — practical
  • ByteByteGo — YouTube + newsletter
  • High Scalability — blog (real cases)
  • Engineering blogs: Uber, Stripe, Netflix, Cloudflare, Discord, Meta, Pinterest, Airbnb, Slack
  • AI/LLM systems: Anthropic Engineering, OpenAI Engineering blog (ระบบ inference สเกลใหญ่ + agent architecture)

← กลับสารบัญหลัก