Volume 2 · Architecture & Topology
เล่มนี้ตอบคำถามเดียว — "ระบบ VTRC มีโครงสร้างเป็นอย่างไร ถ้ามองจากข้างบน"
Volume 1 เล่าในมุมธุรกิจ (ใครทำอะไร ทำไม) เล่มนี้เล่าในมุมวิศวกรรม — กี่บริการ กี่ process กี่ database วิ่งเข้าหากันอย่างไร เปิด port อะไร เก็บ state ที่ไหน ตายอย่างไร
ใครควรอ่าน
- Engineer ใหม่เข้าทีม — อ่าน 2.1 และ 2.2 ก่อน แล้วข้ามไป 2.8 เพื่อรู้ว่าอะไรเปราะบาง
- Architect ที่จะวางแผน modernization — เริ่มที่ 2.5 และ 2.8 ก่อน แล้วย้อนขึ้นไปดู topology ใน 2.2
- DevOps ที่ดูแล production — 2.2, 2.6, 2.7 คือใจกลาง
- QA ที่จะ reproduce bug — 2.3 (request lifecycle) บอกว่า bug อาจเกิดที่จุดไหนระหว่างทาง
สิ่งที่ Volume 2 ไม่ทำ
- ไม่เจาะลึกโค้ดของแต่ละ repo — นั่นอยู่ใน Volume 3-7 (deep dive per repo)
- ไม่ลงรายละเอียด data model — นั่นอยู่ใน Volume 8
- ไม่ลง security hole แบบเจาะลึก — นั่นอยู่ใน Volume 9 และ Audit Docs
- ไม่ให้ runbook ฉุกเฉิน — นั่นอยู่ใน Volume 13
เล่มนี้เป็น แผนที่ สำหรับให้คนรู้ว่าตัวเองอยู่ตรงไหนของระบบ ก่อนจะเจาะลึกในเล่มอื่น
สารบัญ
| บท | หัวข้อ | คำถามที่ตอบ |
|---|---|---|
| 2.1 | ภาพรวมสถาปัตยกรรม | มีกี่บริการ ใครคุยกับใคร ทำไมถึงเป็นแบบนี้ |
| 2.2 | Topology จริงใน production | host อะไร port อะไร กี่ container |
| 2.3 | Request lifecycle | request หนึ่งครั้งวิ่งผ่านกี่ชั้น |
| 2.4 | การเชื่อมต่อระบบภายนอก | HRMI, LDAP, KBANK, SMS, SFTP เชื่อมอย่างไร |
| 2.5 | Data flow + caching | ข้อมูลเข้าออกอย่างไร Redis ใช้จริงไหม |
| 2.6 | Concurrency + batch jobs | cron อะไรบ้าง ทำงานที่ไหน |
| 2.7 | Cross-cutting concerns | logging, error, observability เป็นอย่างไร |
| 2.8 | ข้อจำกัดทางสถาปัตยกรรม + debt | อะไรผิดธรรมดา อะไรเปราะบาง |
วิธีอ่านเล่มนี้
ทุกบทมี 3 ส่วน
- ภาพรวม — อธิบาย concept ใน 1-2 ย่อหน้าก่อน
- รายละเอียดพร้อม file:line reference — ให้ engineer ไปเปิดดูโค้ดจริงได้
- "เคล็ดลับตอนทำงานจริง" — opinion ของเราที่ทำระบบนี้ — จุดที่มักเข้าใจผิด จุดที่ต้องระวัง
ถ้าอ่านแล้วสงสัยว่า "ทำไมไม่เล่าเรื่อง X" — ลองดูสารบัญ Volume ข้างเคียง อาจอยู่ที่นั่น