คุณประมาณการขนาด (scale) และทำ capacity planning อย่างไร?

Question

Accepted Answer

**การประมาณการและ capacity planning** — การคำนวณภาระงานที่คาดหวัง ปริมาณข้อมูล และความต้องการทรัพยากร — เป็นส่วนสำคัญของการออกแบบระบบ การคำนวณคร่าว ๆ แบบ "back-of-the-envelope" ช่วยให้ข้อมูลในการตัดสินใจออกแบบ (ควรขยายขนาดเท่าไร ต้องการทรัพยากรอะไร) และพบบ่อยในการสัมภาษณ์การออกแบบ

## ทำไมการประมาณการจึงสำคัญ

```text
Estimating scale informs DESIGN decisions:
  → how many servers? how much storage? what database? do you need sharding/caching?
  → understanding the SCALE (small vs massive) shapes the whole design
→ rough numbers guide whether/how to scale (don't over- or under-engineer)
```

## สิ่งที่ต้องประมาณ (back-of-the-envelope)

```text
✓ TRAFFIC → users, requests/sec (QPS); read vs write ratio (e.g. 100:1 reads:writes)
  → peak vs average (design for peak); daily active users → requests
✓ STORAGE → data size per item × volume × growth over time → total storage (and growth rate)
✓ BANDWIDTH → data transferred per second (request size × QPS)
✓ MEMORY → cache size needed (e.g. cache the hot 20% of data)
→ rough estimates (order of magnitude) → good enough to inform design
```

## ตัวเลขที่มีประโยชน์และแนวทาง

```text
→ Know rough "latency numbers": memory ~ns, SSD ~µs, network/disk ~ms, cross-region ~100ms
→ Round numbers; use powers of 10; estimate, don't seek precision
→ Example: 1M daily users × 10 requests = 10M/day ≈ ~115 req/sec average (× peak factor)
→ derive resource needs from the estimates → justify the architecture
→ CAPACITY PLANNING → provision for expected load + growth + headroom; plan to scale
```

## ทำไมจึงสำคัญ

การเข้าใจวิธีประมาณการขนาดและทำ capacity planning เป็นความรู้ระดับ senior ที่มีคุณค่า เพราะ **การประมาณการช่วยให้ข้อมูลในการตัดสินใจออกแบบระบบ** และเป็นส่วนที่พบบ่อยของงานออกแบบและการสัมภาษณ์ จึงเป็นทักษะที่มีประโยชน์และใช้ได้จริง

การประมาณการขนาด — การคำนวณภาระงานที่คาดหวัง ปริมาณข้อมูล และความต้องการทรัพยากรผ่านการคำนวณคร่าว ๆ แบบ "back-of-the-envelope" — สำคัญเพราะ **การเข้าใจขนาดกำหนดรูปร่างการออกแบบทั้งหมด**: การรู้ว่าระบบรองรับคำขอเป็นพันหรือเป็นพันล้านกำหนดว่าควรขยายขนาดเท่าไร ควรใช้ฐานข้อมูลอะไร และจำเป็นต้องมี sharding และ caching หรือไม่ ช่วยหลีกเลี่ยงทั้ง over-engineering (ความซับซ้อนที่ไม่จำเป็นสำหรับขนาดเล็ก) และ under-engineering (การออกแบบที่รองรับภาระงานจริงไม่ได้)

การเข้าใจ **สิ่งที่ต้องประมาณ** — **traffic** (ผู้ใช้, คำขอต่อวินาที, อัตราส่วน read/write, peak กับ average), **storage** (ขนาดข้อมูลและการเติบโต), **bandwidth** และความต้องการ **memory/cache** — ให้กรอบในการกำหนดขนาดระบบ

การเข้าใจ **แนวทาง** — การรู้ตัวเลข latency คร่าว ๆ (memory กับ SSD กับ network กับ cross-region), การใช้ตัวเลขกลม ๆ และเลขยกกำลัง 10, การประมาณการระดับ order-of-magnitude แทนที่จะหาความแม่นยำ, การอนุมานความต้องการทรัพยากรจากการประมาณการเพื่อให้เหตุผลกับสถาปัตยกรรม และ **capacity planning** (การจัดสรรสำหรับภาระงานที่คาดหวังบวกการเติบโตและพื้นที่สำรอง) — สะท้อนทักษะเชิงปฏิบัติในการประมาณการที่มีประโยชน์อย่างรวดเร็ว

นี่เป็นทักษะที่พบบ่อยและถูกคาดหวังในการสัมภาษณ์การออกแบบระบบ (ที่ซึ่งการประมาณการแบบ back-of-the-envelope แสดงว่าคุณให้เหตุผลเกี่ยวกับขนาดได้) และในการ capacity planning จริง

เนื่องจากการประมาณการขนาดช่วยให้ข้อมูลในการตัดสินใจออกแบบสำคัญ (จะขยายขนาดอย่างไร ต้องการทรัพยากรอะไร หลีกเลี่ยง over/under-engineering) และเป็นส่วนที่พบบ่อยของงานออกแบบระบบและการสัมภาษณ์ และเนื่องจากการเข้าใจสิ่งที่ต้องประมาณและวิธีการ (การคำนวณ back-of-the-envelope, ตัวเลข latency, capacity planning) เป็นทักษะที่ใช้ได้จริง การเข้าใจวิธีประมาณการขนาดและทำ capacity planning จึงเป็นความรู้ระดับ senior ที่มีคุณค่า — เป็นทักษะที่มีประโยชน์และถูกคาดหวังสำหรับการออกแบบระบบที่ช่วยให้ข้อมูลในการตัดสินใจด้านสถาปัตยกรรมผ่านการให้เหตุผลเชิงปริมาณคร่าว ๆ พบบ่อยทั้งในการ capacity planning จริงและการสัมภาษณ์การออกแบบ และสะท้อนความสามารถในการวางรากฐานการออกแบบบนการประมาณการขนาดและความต้องการทรัพยากรที่สมจริง