Core Infrastructure Concepts - System Design, Simply Explained

บทความนี้จะอธิบายพื้นฐานของ Core Infrastructure Concepts ในมุมมองของ System Design โดยเล่าต่อจากตัวอย่าง Gym Application ในบทความ Data & Storage Concepts เพื่อให้เห็นว่า Request หนึ่งจาก Client ต้องผ่านอะไรบ้างก่อนจะไปถึง Backend, Database หรือ Storage

จากบทความ Data & Storage Concepts ตอนนี้ Gym Application เริ่มเติบโตขึ้น จากเดิมที่มีเพียงสาขาเดียว กลายเป็นหลายสาขาในหลายจังหวัด และมีลูกค้าใช้งานพร้อมกันมากขึ้นในช่วง Peak Hour เช่น ตอนเช้าก่อนเข้างาน ตอนเย็นหลังเลิกงาน หรือช่วงเปิดจองคลาสยอดนิยม

บทความอื่นๆ ที่เกี่ยวข้องกัน

• Distributed Systems Concepts - System Design, Simply Explained
• Database & Storage Concepts - System Design, Simply Explained
• Communication Concepts - System Design, Simply Explained

Functional requirements

• ลูกค้าสมัครสมาชิกและเลือกแพ็กเกจได้
• ลูกค้าชำระเงินค่าสมาชิกได้
• ลูกค้าจองคลาสและเทรนเนอร์ได้
• ลูกค้าสแกน QR Code เพื่อเข้ายิมได้
• Admin อัปโหลดรูปคลาส รูปเทรนเนอร์ และเอกสารสัญญาได้
• ระบบสามารถดูประวัติการเปลี่ยนแปลงของสมาชิกได้

Requirements ของระบบยังเหมือนเดิม แต่สิ่งที่เปลี่ยนไปคือจำนวนผู้ใช้และปริมาณ Request ที่เพิ่มขึ้น ทำให้ทีมพัฒนาต้องเริ่มคิดมากกว่าแค่เรื่อง Business Logic หรือ Database

Scalability
Scalability คือความสามารถของระบบในการรองรับการเพิ่มขึ้นของจำนวนผู้ใช้ ข้อมูล หรือ Requests

ลองดู Use Case ในระบบ Gym Application ช่วงแรกอาจมีผู้ใช้ไม่เยอะ เราใช้ API Server เครื่องเดียว Database เครื่องเดียว และ Object Storage หนึ่งตัวก็พอ แต่เมื่อระบบโตขึ้น ปัญหาจะเริ่มชัดขึ้น

• หน้า Home โหลดช้า เพราะทุกคนดึงรูปคลาสจาก Server เดียว
• การจองคลาสช้า เพราะ API Server รับ Request ไม่ทัน
• Database มี Load สูง เพราะทุก Request อ่านข้อมูลจาก Database ตรงๆ
• ถ้า Server เครื่องเดียวล่ม ลูกค้าจะเข้าแอปไม่ได้ทั้งระบบ

การที่ระบบจะ Scaling ได้ ไม่ได้ขึ้นอยู่กับ Component ใด Component หนึ่ง แต่ขึ้นอยู่กับทั้ง System โดยรวม ตัวอย่างเช่น เราอาจเพิ่มจำนวน Application Server เพื่อรองรับ Traffic ได้มากขึ้น แต่ถ้า Database รองรับไม่ไหว สุดท้าย Database ก็จะกลายเป็น Bottleneck

ข้อดี

• Scalability ช่วยให้ระบบเติบโตตามจำนวนผู้ใช้และจำนวน Request ได้โดยไม่ต้องเปลี่ยนระบบใหม่ทั้งหมด
• เมื่อออกแบบให้ถูกจุด ระบบสามารถเพิ่ม Capacity เฉพาะส่วนที่เป็น Bottleneck ได้ เช่น เพิ่ม API Server, เพิ่ม Cache, เพิ่ม Read Replica หรือย้ายไฟล์ Static ไป CDN

Trade-off

• ระบบที่ Scale ได้มักซับซ้อนขึ้น เพราะต้องมีหลาย Component และต้องดูแลเรื่อง Monitoring, Deployment, Failure, Network และ Data Consistency เพิ่มเติม
• การ Scale ผิดจุดอาจไม่ช่วยอะไร เช่น เพิ่ม API Server จำนวนมาก แต่ Query หลักยังช้าอยู่ที่ Database ระบบก็ยังตอบช้าเหมือนเดิม

Vertical Scaling
Vertical Scaling คือการเพิ่มประสิทธิภาพให้ Server เครื่องเดิม เช่น เพิ่ม CPU, RAM หรือใช้ Storage ที่เร็วขึ้น เพื่อให้รองรับงานได้มากขึ้น โดยไม่ต้องเปลี่ยน Application หรือ Architecture มากนัก วิธีนี้จึงค่อนข้างง่ายและเหมาะกับการเพิ่ม Capacity ในช่วงแรก

ลองดู Use Case ในระบบ Gym Application ถ้า API Server เริ่ม CPU สูง เพราะต้องคำนวณตารางคลาสและสิทธิ์สมาชิกจำนวนมาก การเพิ่ม CPU และ RAM อาจช่วยให้ระบบกลับมาตอบเร็วขึ้นได้ทันที โดยยังไม่ต้องแยก Service หรือเพิ่ม Server หลายเครื่อง

ข้อดี

• Vertical Scaling เริ่มต้นง่าย เพราะไม่ต้องเปลี่ยน Architecture มาก และไม่ต้องจัดการปัญหาการกระจาย Request ไปหลาย Server
• เหมาะกับระบบช่วงแรกที่ยังไม่ได้มี Traffic สูงมาก หรือเหมาะกับ Component บางประเภทที่ Horizontal Scaling ได้ยาก เช่น Database หลักบางตัว

Trade-off

• Server หนึ่งเครื่องอัปเกรดได้ถึงจุดหนึ่งเท่านั้น หลังจากนั้นต้นทุนจะสูงมากเมื่อเทียบกับ Capacity ที่ได้เพิ่ม
• ถ้าระบบพึ่งพา Server เพียงเครื่องเดียว Server นั้นจะกลายเป็น Single Point of Failure เมื่อเครื่องล่ม ระบบทั้งหมดก็ตุยเย่ตามไปด้วย

Horizontal Scaling
Horizontal Scaling คือการเพิ่มจำนวน Server หลายเครื่อง แทนการอัปเกรด Server เครื่องเดิมให้ใหญ่ขึ้น เมื่อระบบมีผู้ใช้หรือ Request เพิ่มขึ้น เราสามารถเพิ่ม Server เพื่อช่วยกันรับงานได้ ทำให้รองรับ Traffic ได้มากขึ้น และถ้า Server เครื่องใดเครื่องหนึ่งล่ม ระบบก็ยังสามารถทำงานต่อได้จากเครื่องอื่น

การทำ Horizontal Scaling มักต้องออกแบบ Application ให้เป็นแบบ Stateless คือไม่เก็บข้อมูลเฉพาะของผู้ใช้ไว้ใน Server เครื่องใดเครื่องหนึ่ง หาก Server เก็บ State ไว้ในเครื่องใดเครื่องหนึ่ง Request ของผู้ใช้คนนั้นจะต้องกลับมาที่ Server เครื่องเดิมเสมอ ทำให้กระจาย Request ไปยัง Server เครื่องอื่นได้ยาก และลดความยืดหยุ่นของ Horizontal Scaling

ลองดู Use Case ในระบบ Gym Application ถ้าลูกค้า 10,000 คนเปิดจองคลาส HIIT พร้อมกันตอน 18:00 น. API Server เครื่องเดียวอาจรับไม่ไหว เราสามารถเพิ่ม API Server เป็นหลายเครื่อง แล้วให้ Load Balancer กระจาย Request ไปยังแต่ละเครื่อง

สิ่งสำคัญคือ Session ของผู้ใช้ไม่ควรเก็บใน Memory ของ API Server เครื่องใดเครื่องหนึ่ง ควรเก็บใน Shared Store เช่น Redis หรือใช้ Token ที่ตรวจสอบได้เอง เช่น JWT เพื่อให้ Request ใดก็ได้สามารถไปที่ API Server เครื่องใดก็ได้

ข้อดี

• Horizontal Scaling ช่วยเพิ่ม Capacity โดยเพิ่มจำนวน Server ได้ และช่วยให้ระบบทนต่อความเสียหายของ Server บางเครื่องได้ดีขึ้น
• เหมาะกับ Stateless Service เช่น API Server, Worker หรือ Service ที่สามารถรับงานแยกกันได้

Trade-off

• ระบบต้องมี Load Balancer, Health Check, Deployment Strategy และ Observability ที่ดีขึ้น
• ถ้า Application ยังเก็บ State ไว้ในเครื่องเดียว หรือมีงานที่ต้อง Lock กันมาก การเพิ่ม Server อาจไม่ได้ช่วยมาก และทำให้ Debug ยากขึ้น

Latency
Latency คือเวลาที่ใช้ตั้งแต่เริ่มส่ง Request จนได้รับ Response กลับมา ในมุมผู้ใช้คือความรู้สึกว่าแอปเร็วหรือช้า

Latency ไม่ได้เกิดจาก Backend เพียงอย่างเดียว แต่เกิดขึ้นได้ตั้งแต่ Request ถูกส่งออกจาก Client ผ่าน Network และส่วนประกอบต่าง ๆ ของระบบ เช่น

• DNS lookup
• TCP/TLS connection
• Network distance
• CDN cache hit หรือ cache miss
• Reverse Proxy processing
• API Gateway authentication หรือ rate limit
• API Server processing
• Cache หรือ Database query
• Serialization และ Response transfer

Latency Numbers Every Programmer Should Know คือเครื่องมือหนึ่งที่ช่วยให้เห็นว่า Operation แต่ละแบบมีต้นทุนต่างกัน เช่น อ่านจาก Memory เร็วกว่าการอ่านจาก Disk และการส่งข้อมูลข้าม Network หรือข้าม Region มีต้นทุนสูงกว่าการทำงานในเครื่องเดียว

ลองดู Use Case ในระบบ Gym Application ลูกค้าสแกน QR Code เพื่อเข้ายิม โดย Request นี้อาจผ่านขั้นตอนประมาณนี้

Mobile App -> DNS -> API endpoint -> Reverse Proxy -> API Gateway ตรวจ token และ rate limit -> Check-in API -> Cache อ่านสถานะสมาชิก -> Database บันทึก check_in_logs -> Response กลับไปเปิดประตู

ผู้ใช้คาดหวังว่าประตูต้องเปิดแทบจะทันที ถ้า Request นี้ใช้เวลา 3-5 วินาที ลูกค้าจะรู้สึกว่าระบบเสีย แม้ระบบจะยังทำงานถูกต้องอยู่ก็ตาม

หากต้องการลด Latency เราสามารถปรับปรุงได้หลายจุด เช่น Cache ข้อมูลสมาชิกที่ถูกอ่านบ่อย ลด Query ที่ไม่จำเป็น แยกการเขียน Event สำหรับ Analytics ไปประมวลผลแบบ Asynchronous หรือวาง Service ให้ใกล้กับพื้นที่ที่มีผู้ใช้จำนวนมาก

ข้อดี

• การวัด Latency ช่วยให้เห็นประสบการณ์จริงของผู้ใช้ โดยเฉพาะ Request สำคัญ เช่น Login, Payment, Booking และ Check-in
• การดู Latency แบบ percentile เช่น p50, p95, p99 ช่วยให้เห็นปัญหาที่ค่าเฉลี่ยอาจซ่อนไว้ เช่น ผู้ใช้ส่วนใหญ่เร็ว แต่ผู้ใช้บางกลุ่มช้ามาก

Trade-off

• การลด Latency มักแลกกับต้นทุนและความซับซ้อน เช่น เพิ่ม Cache, เพิ่ม CDN, เพิ่ม Region, ทำ Async Processing หรือเปลี่ยน Data Model ให้เหมาะกับการอ่าน
• บางครั้งการลด Latency อาจแลกกับความสดของข้อมูล เช่น อ่านจาก Cache หรือ Replica จะเร็วกว่า แต่มีโอกาสได้ข้อมูลที่ยังไม่อัปเดตล่าสุด

Throughput
Throughput คือปริมาณงานที่ระบบรองรับได้ในช่วงเวลาหนึ่ง เช่น Requests per second (RPS), Queries per second (QPS), Messages per second หรือ Transactions per second

Latency กับ Throughput เป็นคนละเรื่องกัน ระบบหนึ่งอาจตอบเร็วมากเมื่อมีผู้ใช้ 10 คน แต่พอมีผู้ใช้ 10,000 คนพร้อมกัน Latency อาจพุ่งขึ้น เพราะ Throughput ของระบบเต็มแล้ว

ลองดู Use Case ในระบบ Gym Application ตอนเปิดจองคลาสยอดนิยม ระบบอาจมี Request เข้ามาพร้อมกันจำนวนมาก

• ลูกค้ากดดูรายละเอียดคลาส
• ลูกค้ากดจองคลาส
• ลูกค้ากดชำระเงิน
• ลูกค้ากด Refresh เพื่อดูจำนวนที่นั่งคงเหลือ

ถ้าระบบรองรับได้ 500 RPS แต่มี Request เข้ามา 2,000 RPS ระบบจะเริ่มรับไม่ไหว ทำให้บาง Request ต้องรอนานขึ้น บาง Request อาจ Timeout หรือถูกปฏิเสธด้วย Rate Limit

วิธีเพิ่ม Throughput อาจทำได้หลายแบบ เช่น เพิ่ม API Server, ใช้ Load Balancer กระจาย Request, Cache ข้อมูลคลาสที่ถูกอ่านบ่อย, แยกงานหนักไป Queue, ทำ Database Index หรือจำกัด Rate สำหรับ Endpoint ที่ถูกยิงซ้ำเยอะ

ข้อดี

• การวัด Throughput ช่วยให้รู้ว่าระบบรองรับ Load ได้แค่ไหน และต้องเพิ่ม Capacity เมื่อใด
• Throughput เหมาะกับการวางแผน Capacity เช่น ถ้า Peak Hour มี 3,000 RPS ระบบต้องมี API Server, Database, Cache และ Network ที่รับไหวทั้งเส้นทาง
  

Trade-off

• การเพิ่ม Throughput โดยไม่ควบคุม Load อาจทำให้ Component ด้านหลังล่ม เช่น API Server รับไหว แต่ Database รับไม่ไหว
• บางเทคนิคช่วยให้ระบบรองรับงานได้มากขึ้น แต่ผู้ใช้อาจต้องรอผลลัพธ์นานขึ้น เช่น Batch Processing หรือ Queue ที่ช่วยกระจายงานไปประมวลผลภายหลัง

CDN (Content Delivery Network)
CDN คือเครือข่าย Server ที่กระจายอยู่ในหลายพื้นที่ ทำให้สามารถส่ง Content จาก Server ที่อยู่ใกล้ผู้ใช้ได้มากกว่า Origin เหมาะกับ Static Content เช่น รูปภาพ วิดีโอ CSS JavaScript และไฟล์ต่าง ๆ แนวคิดหลักคือไม่ต้องให้ทุก Request กลับไปที่ Server หลักเสมอ ถ้า CDN มีไฟล์นั้นเก็บไว้แล้ว ก็สามารถส่งไฟล์ให้ผู้ใช้ได้ทันทีจาก Server ที่อยู่ใกล้กว่า ช่วยให้โหลดเร็วขึ้น และลดภาระของ Server หลักด้วย

เมื่อระบบโตขึ้น การย้าย Static Content ไป CDN เป็นหนึ่งในวิธีสำคัญในการลด Load/Response Time และลดภาระของ Web Tier

ลองดู Use Case ในระบบ Gym Application หน้า Home มีรูปคลาส รูปเทรนเนอร์ รูปโปรโมชัน และวิดีโอแนะนำท่าออกกำลังกาย ถ้าทุกคนโหลดไฟล์เหล่านี้จาก API Server หรือ Object Storage โดยตรง ระบบจะใช้ Bandwidth เยอะและ Origin จะรับ Load โดยไม่จำเป็น เราสามารถวาง Flow แบบนี้

• Mobile App ขอรูป class-cover.jpg
• CDN Edge
• ถ้ามี Cache ส่งกลับทันที
• ถ้าไม่มี Cache ดึงจาก Object Storage หรือ Origin
• เก็บไว้ที่ CDN จนกว่า TTL หมดอายุ

ข้อดี

• CDN ลด Latency เพราะผู้ใช้รับไฟล์จาก Edge ที่ใกล้กว่า Origin
• CDN ลด Load และ Bandwidth ที่ Origin เพราะ Static Content ที่ถูกเรียกซ้ำสามารถตอบจาก Cache ได้โดยตรง

Trade-off

• ต้องออกแบบ Cache TTL และ Invalidation ให้ดี ถ้าตั้ง TTL ยาวเกินไป ผู้ใช้อาจเห็นรูปหรือไฟล์เก่า ถ้าสั้นเกินไป CDN จะต้องกลับไปดึงจาก Origin บ่อย
• CDN มีต้นทุนและมี Failure Mode ของตัวเอง ถ้า CDN มีปัญหา ระบบต้องคิดว่าจะ Fallback ไป Origin ได้หรือไม่ และ Static URL ควรออกแบบให้เปลี่ยน Version ได้ง่าย เช่น ใช้ชื่อไฟล์แบบมี hash

DNS (Domain Name System)
DNS คือระบบที่แปลงชื่อ Domain ที่มนุษย์จำได้ เช่น api.gym.example.com ให้เป็น IP Address หรือปลายทางที่ระบบใช้เชื่อมต่อจริง

DNS เป็นจุดเริ่มต้นของการเข้าใช้งานระบบ ถ้า DNS ช้า ผู้ใช้จะเริ่มเชื่อมต่อช้า ถ้า DNS ล่ม ผู้ใช้อาจเข้าแอปไม่ได้ แม้ Backend ทั้งหมดจะยังทำงานอยู่
ลองดู Use Case ในระบบ Gym Application เราอาจมี Domain แบบนี้

• www.gym.example.com สำหรับ Web App
• api.gym.example.com สำหรับ API
• assets.gym.example.com สำหรับรูปและไฟล์ผ่าน CDN
• admin.gym.example.com สำหรับระบบ Admin

เมื่อผู้ใช้เปิดแอป ระบบต้อง Resolve Domain ก่อน เพื่อหาว่า Request ควรถูกส่งไปยังปลายทางใด เช่น api.gym.example.com อาจชี้ไปที่ Load Balancer ส่วน assets.gym.example.com อาจชี้ไปที่ CDN ตัวอย่าง Flow

• Mobile App ต้องเรียก api.gym.example.com
• ถาม DNS Resolver
• Resolver ได้คำตอบจาก Authoritative DNS หรือ Cache
• ได้ปลายทางของ Load Balancer
• App เริ่มเชื่อมต่อไปยังปลายทางนั้น

ข้อดี

• DNS ช่วยแยกชื่อที่ผู้ใช้หรือ Client เรียกใช้ออกจาก Infrastructure จริง ทำให้เปลี่ยน IP, เปลี่ยน Load Balancer หรือย้าย Region ได้โดยไม่ต้องเปลี่ยนแอป
• DNS สามารถใช้ร่วมกับ CDN, Load Balancer และ Multi-region routing เพื่อพาผู้ใช้ไปยังปลายทางที่เหมาะสมได้

Trade-off

• DNS มี Cache และ TTL ทำให้การเปลี่ยน Record อาจไม่ได้มีผลทันทีทุกที่ ถ้าตั้ง TTL ยาว การย้าย Traffic ตอนเกิด Incident อาจช้า
• ถ้าระบบพึ่งพา DNS Provider เดียว และ Provider มีปัญหา Domain สำคัญอาจ Resolve ไม่ได้ จึงต้องพิจารณาเรื่องความน่าเชื่อถือของ Authoritative DNS ด้วย

Reverse Proxy
Reverse Proxy คือ Server ที่รับ Request จาก Client ก่อน Backend แล้วจึงส่งต่อ Request ไปยัง Backend ที่เหมาะสม

Reverse Proxy ใช้ทำงานได้หลายอย่าง เช่น TLS termination, compression, caching, request buffering, routing ตาม path, เพิ่มหรือลบ header, logging, basic protection และซ่อนรายละเอียดของ Backend

ลองดู Use Case ในระบบ Gym Application เราอาจใช้ Reverse Proxy เป็นด่านหน้าของ Web และ API

• Reverse Proxy ->
• /api/ ส่งไป API Gateway
• /admin/ ส่งไป Admin Web
• /health ส่งไป Health Endpoint

Reverse Proxy สามารถจัดการ TLS ให้ Backend ไม่ต้องถือ Certificate เองทุกตัว และสามารถเพิ่ม Header เช่น X-Request-Id เพื่อให้ Trace Request ได้ตั้งแต่ด่านหน้าไปจนถึง API Server

ข้อดี

• Reverse Proxy ช่วยซ่อน Backend Server และรวมงานที่ควรอยู่ด้านหน้าไว้ที่จุดเดียว เช่น TLS, routing, logging และ compression
• ช่วยให้เปลี่ยน Backend ด้านหลังได้ง่ายขึ้น เพราะ Client ไม่ต้องรู้ว่า Service จริงอยู่เครื่องไหนหรือ Port ไหน

Trade-off

• Reverse Proxy กลายเป็น Component สำคัญ ถ้าตั้งค่าไม่ดีอาจกลายเป็น Bottleneck หรือ Single Point of Failure
• การตั้งค่า Header, Timeout, Buffer และ Routing ผิดอาจทำให้เกิด Bug ที่ตามหายาก เช่น Client IP หาย, Upload ไฟล์ใหญ่ไม่ได้ หรือ Request ถูกตัดก่อน Backend ทำงานเสร็จ

Load Balancer
Load Balancer คือ Component ที่ทำหน้าที่กระจาย Request ไปยัง Server หลายเครื่อง เพื่อให้ระบบรองรับ Traffic ได้มากขึ้น และยังสามารถทำงานต่อได้แม้ Server บางเครื่องมีปัญหา

เมื่อระบบขยายจาก Server เครื่องเดียวเป็นหลายเครื่อง Load Balancer มีหน้าที่เลือกว่าจะส่งแต่ละ Request ไปที่ Server เครื่องไหน เพื่อไม่ให้ Server เครื่องใดเครื่องหนึ่งรับงานหนักเกินไป

ลองดู Use Case ในระบบ Gym Application ตอน 18:00 น. มีลูกค้ากดจองคลาสพร้อมกันจำนวนมาก เราเพิ่ม API Server เป็น 4 เครื่อง แล้ววาง Load Balancer ไว้ข้างหน้า

• Load Balancer
• API Server 1
• API Server 2
• API Server 3
• API Server 4

ถ้า API Server 2 ล่ม Health Check จะตรวจพบและหยุดส่ง Request ไปยังเครื่องนั้น ส่วน Request ใหม่จะถูกส่งไปเครื่องที่ยัง Healthy เช่น API Server 1, API Server 3 และ API Server 4

ข้อดี

• Load Balancer ช่วยให้ระบบรองรับ Traffic ได้มากขึ้นโดยกระจายงานไปหลาย Server
• ช่วยเพิ่ม Fault Tolerance เพราะ Server บางเครื่องล่มได้โดยไม่ทำให้ระบบทั้งหมดหยุดทำงาน

Trade-off

• Load Balancer ต้องถูกออกแบบให้ทนทานด้วย ถ้ามีตัวเดียวและล่ม ก็กลายเป็น Single Point of Failure เช่นกัน
• ถ้าใช้ Sticky Session เพื่อบังคับให้ผู้ใช้กลับไป Server เครื่องเดิม การเพิ่มหรือลด Server จะยากขึ้น และถ้า Server เครื่องนั้นล่ม ผู้ใช้กลุ่มนั้นอาจได้รับผลกระทบมากกว่าปกติ

API Gateway
API Gateway คือด่านหน้าของ API ทำหน้าที่รับ Request จาก Client ก่อนส่งต่อไปยัง Service ด้านหลัง พร้อมจัดการเรื่องที่หลาย API ใช้ร่วมกัน เช่น Authentication, Authorization, Rate Limiting, Request Validation, Routing, Monitoring และ Logging

ในขณะที่ Load Balancer เน้นกระจาย Traffic ไปยัง Server หลายเครื่อง API Gateway จะเน้นควบคุมว่าใครสามารถเรียก API ได้ เรียกได้มากแค่ไหน และ Request ควรถูกส่งไปยัง Service ใด

ใน Distributed System มักวาง API Gateway ไว้ด้านหน้า Service ต่าง ๆ เพื่อรับและควบคุม Request จาก Client ก่อนส่งต่อไปยัง Service ที่เกี่ยวข้อง เช่น ใน Gym Application อาจมี

• Member API
• Booking API
• Payment API
• Check-in API
• Admin API

ข้อดี

• API Gateway รวม Logic ที่ทุก API ต้องใช้ไว้ที่จุดเดียว เช่น Auth, Rate Limit, Logging, Versioning และ Routing ทำให้ Service ด้านหลังโฟกัสที่ Business Logic ได้มากขึ้น
• ช่วยป้องกัน Backend จาก Traffic ที่ไม่ควรเข้าไปถึง Service จริง เช่น Request ที่ไม่มี Token, Request เกิน Rate Limit หรือ Request รูปแบบผิด

Trade-off

• API Gateway อาจเพิ่ม Latency เพราะทุก Request ต้องผ่านการตรวจสอบและ Routing เพิ่มอีกชั้น
• ถ้าใส่ Business Logic เข้าไปใน Gateway มากเกินไป Gateway จะกลายเป็นจุดรวมความซับซ้อน และการเปลี่ยน API กระทบหลาย Service พร้อมกัน

สรุป
Scalability คือความสามารถของระบบในการรองรับการเติบโต ส่วน Vertical Scaling และ Horizontal Scaling คือวิธีเพิ่ม Capacity ของระบบคนละแบบ

Latency คือเวลาที่ผู้ใช้ต้องรอ ส่วน Throughput คือปริมาณงานที่ระบบรองรับได้ในช่วงเวลาหนึ่ง ทั้งสองอย่างต้องดูคู่กัน เพราะระบบที่เร็วตอนมีผู้ใช้น้อย อาจช้าลงมากเมื่อ Traffic เพิ่มจนเกิน Capacity

CDN ช่วยส่ง Static Content จากจุดที่ใกล้ผู้ใช้มากขึ้น DNS ช่วยพา Request ไปยังปลายทางที่ถูกต้อง Reverse Proxy ช่วยรับ Request ก่อนเข้า Backend Load Balancer ช่วยกระจาย Request ไปยังหลาย Server และ API Gateway ช่วยควบคุม Request ก่อนส่งต่อไปยัง Service

Refs

Amazon.com

50 System Design Concepts Explained Simply [2026 Edition]

Fifty of the Most Important System Design Concepts, Each Explained Simply and Clearly With What It Does, Why It Exists, and When to Use It

System Design NuggetsArslan Ahmad